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SECTION  I 


INTRODUCTION  AND  BACKGROUND 


The  Force  Level  Automated  Planning  System  (FLAPS)  is  a  computer  software 
package  developed  by  Systems  Control  Technology,  Inc.  (SCT)  for  the  United 
States  Air  Forces  in  Europe  (USAFE).  FLAPS  applies  powerful  mathematical 
optimization  algorithms,  detailed  mathematical  models,  and  large  data  bases  to 
automatically  perform  critical  force  planning  functions.  FLAPS  was  not  designed 
to  be  used  operationally.  However,  it  is  a  demonstration  system  that  shows  how 
modern  mathematical  optimization  techniques  and  computer  systems  can  assist 
planners  in  quickly  generating  operating  plans  with  totally  effective  use  of 
limited  assets. 

FLAPS  was  developed  un«er  a  contract  with  the  USAFE  Directorate  of 
Operations  (USAFE/DO).  Under  this  contract,  an  existing  SCT  computer  program 
named  AUTOPATH  was  modified  to  meet  the  needs  of  USAFE.  The  AUTOPATH  data  bases 
were  changed  and  expanded  to  support  the  requirements  of  force  planners  in  the 
European  central  theater. 

This  document  describes  FLAPS  -  its , performance,  development,  and 


supporting  data  bases. 


1 . 1  BACKGROUND 


Force  planners  at  a  NATO  ATOC  face  a  very  complicated  oroolem.  The 
planner's  overall  objectives  are  stated  in  the  Daily  Operations  Order  (DOO) 
generated  by  the  NATO  ATAF.  The  planner  must  assign  available  assets  to  targets 
specified  in  the  DOO.  Ultimately,  the  planner  vill  generate  Air  Tasking  Orders 
(ATO's)  and  Air  Tasking  Messages  (ATM' s) • that  assign  NATO  attack  aircraft  to 
specific  targets.  ATO's  and  ATM's  vill  also  be  issued  to  NATO  support  aircraft, 
i.e.,  particular  ETJ  support  aircraft  and  tankers.  These  aircraft  vill  be 
assigned  to  locations  vhere  they  can  support  the  penetrating  attack  aircraft. 

Generating  ATO's  and  ATM's  is  complicated  by  many  factors.  First,  the 
aircraft  available  to  meet  the  objectives  of  the  DOO  are  spread  out  over  many 
staging  bases.  Each  staging  base  has  its  ovn  inventory  of  aircraft  and  veapons. 
Vhen  assigning  assets  from  a  particular  staging  base  to  a  specific  target,  the 
planner  must  insure  that  aircraft  are  available;  appropriate  veapons  exist  at 
the  staging  base;  the  aircraft  can  deliver  those  veapons;  and  the  target  is 
vithin  range  of  the  aircraft.  These  constraints  must  be  considered  vithin  the 
context  of  the  Airspace  Coordination  Order  (ACO),  vhich  restricts  the  vay  the 
penetrating  aircraft  can  fly  through  friendly  airspace. 

In  addition,  the  enemy  threat  must  be  considered  to  insure  the  assigned 
missions  are  survivable.  In  the  1985-1995  timeframe,  and  beyond,  the  fixed  and 
mobile  threats  vill  be  extremely  dense,  rapidly  changing,  and  lethal.  These 
threats  must  be  considered  if  the  penetrating  aircraft  are  to  safely  reach  their 
targets  and  return. 


Fortunately,  current  support  aircraft  can  reduce  or  eliminate  the  threats 
and  significantly  increase  the  probability  that  the  attack  aircraft  will  safely 
complete  their  missions.  The  availabilty  of  this  support  will  affect  the 
assignment  of  attack  aircraft.  The  attack  and  support  aircraft  must  be 
considered  simultaneously  to  maximize  force  effectiveness. 

Finally,  the  planner  is  under  time  pressure  to  output  the  ATO's  and 
ATM's.  Vhile  data  regarding  the  available  assets  and  the  locations  of  enemy 
threats  are  available,  the  planner  may  not  have  time  to  quantitatively  analyze 
it.  Without  automated  tools,  gross  approximations  must  be  used.  Errors  here 
could  adversely  impact  the  outcome  of  theater  tactical  operations. 

Many  of  these  problems  are  basically  numerical,  and  require  only  rapid 
access  and  correlation.  For  example,  the  status  of  the  force  (the  number  of 
aircraft  and  weapons  available  at  each  staging  base);  and  performance  data  for 
attack  aircraft  (fuel  flow,  fuel  capacity,  etc.)  are  available  as  numerical 
tables.  Correlating  these  two  data  bases  determines  if  a  target  is  within  range 
of  a  particular  staging  base,  and  if  the  right  type  of  weapon  is  available. 

Vhile  this  is  difficult  and  time  consuming  to  do  by  hand,  it  is  very  simple  to 
do  on  a  computer. 

This  is  the  approach  used  in  FLAPS.  Data  bases  from  multiple  sources  are 
integrated  and  data  is  processed  in  a  way  that  systematically  and  quickly  solves 
the  planning  problem. . .and  optimizes  force  effectiveness. 


BASELINE  AUTO PATH 


SCT's  technical  approach  for  this  effort  vas  to  build  a  tactical  force 
planning  system  for  USAFE  based  upon  an  existing  program  called  AUTOPATH. 
AUTOPATH  is  a  program  developed  by  SCT  under  Defense  Advanced  Research  Projects 
Administration  (DARPA),  Strategic  Air  Command  (SAC),  and  internal  funding.  It 
vas  developed  as  a  research  tool  and  contained  a  great  deal  of  general 
capability.  However,  the  program  vas  not  developed  for  tactical  aircraft  and 
their  special  requirements.  AUTOPATH  did  provide  a  general  mission  planning 
capability  based  on  dynamic  programming  and  probabilistic  threat  modeling.  Thi 
part  of  the  program  vas  the  core  upon  which  FLAPS  vas  based.  (Reference  DARPA 
Seminannual  Reports  describing  Autopath  capabilities). 


1.3  SCOPE  AND  OBJECTIVES  OF  THIS  EFFORT 


SCOPE 


FLAPS  is  a  stand-alone,  proof-of-concept  computer  softvare  package.  The 
program  is  "stand-alone"  in  the  sense  that  there  are  no  automated  interfaces 
vith  other  existing  computer  systems  or  data  bases.  FLAPS  vas  designed  to 
demonstrate  that  powerful  mathematical  optimization  algorithms,  detailed 
mathematical  models,  and  large  data  bases  can  be  integrated  and  used  to 
automatically  perform  force  planning  functions. 

OBJECTIVE 

The'  objective  of  this  effort  vas  to  demonstrate  that  computer  systems 
coupled  vith  optimization  techniques  can  assist  planners  in  quickly  generating 
effective  plans  based  on  limited  attack  and  supression  assets.  To  meet  the 
objective,  the  FLAPS  computer  program  vas  developed  to:  evaluate  the 
feasibility  of  the  technical  approach;  define  operational  system  requirements; 
integrate  existing  government  data  bases;  and  maintain  unit  level  compatibility 


I . 4  REPORT  CONTENTS 


The  approach  taken  on  this  project  involved  building  on  existing  force 
planning  computer  software  and  algorithms.  SCT  and  USAFE/DO  jointly  developed 
the  requirements  for  a  stand-alone  demonstration  system. 

Section  II  describes  the  requirements  considered  during  this  design 
phase.  Included  are  the  technical  modeling  requirements  for  weaponeering  and 
electronic  combat;  a  description  of  the  external  data  bases  requiring  FLAPS 
interface  capability;  the  DMA  and  ESAMS  data;  and  user  interface  requirements. 

Section  III  describes  the  work  done  in  developing  the  FLAPS  software  and 
data  bases.  This  includes  the  key  mathematical  models  and  optimization 
algorithms.  Also  included  is  a  description  of  the  user  interface,  the  data  base 
manager,  and  the  graphics  display  software. 

Section  IV  describes  the  system  performance  of  the  current  FLAPS 
software.  Execution  times  are  given  for  all  major  functions  of  the  program. 

Section  V  describes  the  computer  systems  considerations  SCT  believes  are 
necessary  to  do  operational  force  and  unit  level  planning.  These 
recommendations  are  based  on  SCT's  experience  with  FLAPS  and  its  application  of 
PEN-AIDS  to  unit  level  planning. 

Section  VI  describes  the  modifications  to  FLAPS  that  will  be  required  to 
make  the  system  operational.  The  most  important  consideration  here  is  the 
requirement  for  a  real  time  interface  with  the  European  Communications  System. 


SECTION  II 


REQUIREMENTS 


The  first  major  task  of  the  FLAPS  project  was  to  define  requirements  for 
the  FLAPS  computer  program  and  the  associated  data  bases.  This  task  was 
necessary  to  insure  that  the  program  met  the  special  needs  of  USAF  force 
planners  in  the  European  theater.  These  requirements  determined  which  specific 
capabilities  of  the  existing  AUTOPATH  software  would  be  used,  and  what  new 
capabilities  would  be  developed  using  the  scope  and  objectives  of  this  effort. 

The  requirements  fell  into  three  main  areas;  the  data  base,  the  user 
interface,  and  the  program  modifications  and  enhancements.  They  were  generated 
based  on  detailed  technical  discussions  with  USAFE  personnel.  Each  of  these 
areas  is  described  in  the  following  three  subsections. 

11. 1  DATA  BASE  REQUIREMENTS 

/ 

SCT  and  USAFE  personnel  identified  which  data  bases  where  necessary  to 
perform  force  planning.  These  data  bases  are  discussed  in  detail  in  Section 

111.1  and  Appendix  A. 


SjCT  vas  tasked  to  determine  vhich  data  bases  currently  exist  and  vhich  do 
not.  5CT  found  that  almost  all  of  the  necessary  data  bases  currently  exist, 
although  they  are  not  in  a  format  compatible  vith  SCT's  softvare.  These  data 
bases  are  given  in  Table  1. 

Table  1.  Necessary  Data  Bases 

DMA  DTED  Terrain  Data 
Prioritized  Target  Data 
Threat  Location  Data. 

Threat  Effectiveness  Data 
Weapons  Effectiveness  Data 
Force  Status  Data 
Vehicle  Performance  Data 
Weapons  Free  Zones 
EC  Aircraft- Locations 
EC  Aircraft  Effectiveness  Data 

The  only  critical  data  base  that  does  not  exist  is  one  vhich  defines  the 
planner's  area  of  interest  and  certain  AUTOPATH  program  parameters.  This  data 
base  is  easily  input  by  the  planner,  and  seldom  changes. 

SCT  also  developed  requirements  for  a  data  base  manager  vhich  could 
support  force  level  planning  and  operate  on  the  above  mentioned  data  bases.  SCT 

determined  that  most  of  the  data  could  be  efficiently  stored  in  a  record 

.1  . 

oriented  data  base  system.  However,  the  several  algorithms  required  many  large 
array  oriented  data  structures  to  store  intermediate  and  final  results.  An 
efficient  array  oriented  data  base  system  vas  necessary  for  the  FLAPS  system  to 
handle  arrays  of  data  like  digitized  terrain  elevations  (DTED).  The  arrays 
generated  by  FLAPS  are  discussed  in  Section  III .  1  and  in  APPENDIX  A. 


II— 2 
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USAFE  tasked  SCT  to  determine  requirements  for  interfacing  the  FLAPS 
program  to  existing  data  bases  and  systems.  SCT  completed  this  task  and 
developed  interface  software  for  the  DMA  DTED  and  AFSA  (TAC  ZINGER  and  ESAMS) 
threat  effectiveness  data.  In  addition  SCT  developed  requirements  for 
interfacing  with  other  critical  data  bases,  including  threat  intelligence  data. 
These  requirements  are  discussed  in  Section  VI. 

II. 2  ALGORITHM  DEVELOPMENT  AND  MODIFICATIONS 

The  task  of  identifying  the  technical  requirements  for  the  FLAPS 
algorithms  required  a  great  deal  of  cooperation  between  SCT's  technical  staff 
and  USAFE 's  operational  personnel.  While  SCT’s  AUTOPATH  program  provided  the 
basic  building  blocks  for  the  FLAPS  program,  major  modifications  were  needed  in 
both  the  structure  of  the  program  and  in  the  basic  mathematical  algorithms.  In 
addition,  new  algorithms  were  identified  to  meet  the  special  requirements  of 
USAFE. 


A  large  number  of  detailed  technical  requirements  were  generated  for  the 
FLAPS  program.  These  requirements  can  be  organized  into  the  following  areas: 

Table  2.  Technical  Requirements 


Threat  Modeling 
LLTR  Routing 

Staging  Base  /  Target  Accessibility 
Routing  and  Vehicle  Modeling 
Weapons  Allocation 
Threat  Suppression 


II-3 


The  threat  modeling  area,  required  some  changes  from  the  present  AUTQPATH 
methodology.  The  existing  approach  included  a  threat  .nodeling  procedure  based 
on  generic  threat  effectiveness  data  (threat  templates).  Given  these  threat 
templates,  AUTOPATH  built  a  lethality  space  (s tatespace) ,  based  on  the  position 
of  fixed  and  mobile  threats.  Fixed  threats  vere  terrain  masked.  Mobile  threats 
vere  considered  in  a  probabilistic  fashion  vhich  explicitly  considered  location 
uncertainty.  The  first  priority  vas  to  acquire  threat  template  data  for  all 
threat  types  and  three  aircraft  types  of  interest  to  USAFE  personnel  (F-lll, 
F-16,  r— i).  Second;  an  improved  method  of  performing  the  terrain  masking  while 
saving  the  intermediate  threat  observability  data  vas  developed.  This  vas 
necessary  to  make  feasible  threat  suppression  calculations  on  the  statespace. 
Finally,  an  improved  method  of  calculating  mobile  threat  danger  vas  required. 

The  existing  mobile  threat  mddel  vas  prohibitively  time  consuming,  in  part  due 
to  large  numbers  of  mobile  threats  in  the  operational  area. 

The  requirement  to  support  a  full  LLTR  routing  capability  vas  identified 
early  in  the  program.  USAFE  and  NATO  use  LLTR  points  for  airspace  control  on 
the  friendly  side  of  the  FEBA.  This  is  a  significant  constraint  on  the  vehicle 
flight  paths.  The  existing  AUTOPATH  program  did  not  include  an  LLTR  routing 
capability,  although  a  general  netvork  routing  capability  vas  available. 

Staging  base/ target  accessibility  refers  to  the  rules  used  to  determine 
whether  a  given  target  may  be  attacked  by  a  specific  staging  base.  Aircraft 
range,  target  characteristics,  and  veapons  availablity  are  considered. 
Requirements  for  an  accessibility  algorithm  were  identified  by  SCT  working  vith 
USAFE  personnel.  Accessibili ty  considerations  are  consistent  vith  the  AUTOPATH 
approach;  hovever,  USAFE  requirements  dictated  major  changes  in  this  area  of  the 
FLAPS  program. 


A  key  feature  of  the  AUTOPATH  program  is  the  ability  to  automatically 
generate  aircraft  flight  plans.  This  is  also  a  key  requirement  for  fast  and 
effective  force  planning.  The  AUTOPATH  route  planning  algorithm  did  not 
consider  the  special  requirements  of  tactical  aircraft,  nor  special  routing 
constraints.  Unique  FLAPS  routing  algorithms  were  developed  to  meet  these 
special  needs.  The  routing  algorithm  was  required  to  be  completely  automatic, 
and  produce  maximum  survival  probability  routes  consistent  with  vehicle  range. 
Other  constraints  to  be  considered  vere:  multiple  vehicle  clearance  altitudes; 
SCL's;  SCL  dependent  fuel  capacity  and  fuel  flow  rates;  turn  constraints  over 
the  target;  and  LLTR  routing  constraints. 

SCT  developed  parameters  for  an  automatic  weapons  allocation  algorithm 
based  on  inputs  from  USAFE  personnel  and  planners.  Force  planning  requirements 
dictate  that  this  algorithm  determine  what  type  of  aircraft  will  be  tasked  for 
each  target;  which  staging  base  will  be  used;  what  weapons  will  be  carried;  and 
how  many  aircraft  will  be  tasked.  Enough  weapons  must  be  assigned  to  each 
target  to  reach  a  minimum  probability  of  damage  threshold.  The  weapons 
assignment  algorithm  must  consider  the  total  force  of  attack  aircraft,  and  the 
entire  prioritized  target  list.  Aircraft  must  be  assigned  to  as  many  targets  as 
possible.  Aircraft  and  weapons  availability  constraints  must  be  considered  as  a 
central  part  of  the  weapons  assignment. 

The  FLAPS  program  must  assist  the  force  planners  in  coordinating  attack 
and  EC  aircraft.  In  the  European  theater,  EC  aircraft  will  be  used  to  open  high 
probability  of  survival  corridors.  The  FLAPS  planning  software  must  be 
consistent  with  this  doctrine.  Thus,  the  FLAPS  program  was  required  to  assist 
the  planner  with  the  following:  deciding  where  corridors  should  be  placed; 
selecting  different  possible  corridor  locations;  modeling  in  detail  the 
effectiveness  of  EC  aircraft  against  the  threats  adjacent  to  the  corridors;  and 


producing  attack  aircraft  flight  plans  tnat  taxa  advantage  of  the  corridors. 
Three  types  of  EC  aircraft  mist  be  considered  -  the  EF-111,  the  EC-130H  (Compass 
Call),  and  F~*G  and  F-5E  (Viid  Veasel).  The  model  must  correlate  the 
effectiveness  of  a  variety  of  EC  aircraft  against  a  diversity  of  threats. 

Finally,  the  FLAPS  program  vas  required  to  provide  a  framevork  that  will 
allow  the  models  to  work  together  in  a  fast  and  effective  manner.  Intermediate 
results,  detailed  reports,  and  color  graphics  were  needed  to  show  the  planner 
vhat  is  happening  at  each  step  of  the  planning  process. 

II. 3  USER  INTERFACE  AND  GRAPHICS  DISPLAYS 

SCT  and  USAFE  personnel  determined  requirements  for  the  FLAPS  user 
interface  and  graphics  display  system.  The  resultant  interface  is  discussed  in 
Section  III. 5.  The  preliminary  FLAPS  system  is  a  prototype  and  is  not  meant  to 
be  an  operational  system.  However,  the  program  must  be  as  easy  to  use  as 
possible.  The  requirement  was  to  design  a  user  interface  which  minimized  the 
number  of  required  keystrokes,  yet  maintained  flexibility  in  using  the  program. 

A  detailed  on-line  help  feature  vas  also  needed,  along  with  a  type  ahead  feature 
to  accommodate  expert  users. 

The  force  planner  must  monitor  a  great  deal  of  complex  information  in 
order  to  produce  effective  plans.  This  prompted  development  of  a  color  graphics 
display  system.  It  would  clearly  display  all  critical  planning  data,  while 
allowing  user  inputs  through  the  graphics  display.  The  graphics  display  system 
is  discussed  infection  III. 6. 


SECTION  III 
PROGRAM  MODIFICATIONS 


Major  modifications  vere  made  to  the  AUTOPATH  program  to  meet  USAFE  force 
planning  requirements.  These  changes  affected  all  aspects  of  the  program;  only 
the  basic  underlying  mathematical  algorithms  were  unaffected.  The  result  is  the 
FLAPS  program.  The  program  modifications  and  enhancements  are  described  below. 

The  AUTOPATH  program  provided  powerful  mathematical  algorithms  for  use  by 
both  strategic  and  tactical  mission  planners.  However,  the  progam  was  not 
tailored  to  meet  the  specific  needs  of  USAFE  force  planners.  Early  in  the  FLAPS 
program  design  effort,  a  solution  approach  for  tactical  force  planning  was 
identified.  This  approach  is  referred  to  as  the  "Six  Step  Planning  Approach" 
and  it  guided  the  development  of  the  FLAPS  program.  When  this  approach  was 
understood,  it  allowed  modification  of  the  basic  AUTOPATH  models  and  algorithms 
to  meet  the  specific  requirements  of  USAFE.  The  six  steps  are  listed  in 


Table  3. 


■Tl 


Table  3.  Six  3  tec  Plans  Aooroach 


STEP  1  UPDATE  THE  DATA  BASE. 

STEP  2  DETERMINE  STAGING  BASE  AND  TARGET  ACCESSIBILITY. 

STEP  3  COMPUTE -OPTIMAL  INGRESS  AND  EGRESS  ROUTES  TO  TARGETS. 
STEP  4  ALLOCATE  WEAPONS  TO  TARGETS. 

STEP  5  ALLOCATE  SUPPORT  AIRCRAFT  TO  OPEN  HIGH  PROBABILITY  OF 

SURVIVAL  FLIGHT  CORRIDORS. 

(steps  3.  4,  and  5  nay  be  iterated) 

STEP  6  OUTPUT  ATO's.  ' 


STEP  1  is  to  update  the  force  status  data,  the  current  target  list,  the 
Airspace  Coordination  Order  (ACO).  and  the  current  threat  status.  Force  status, 
target,  and  ACO  data  is  stored  in  the  FLAPS  data  base  and  is  used  continuously 
in  the  remaining  five  steps.  The  threat  data  is  processed  into  the  large 
lethality  or  "statespace"  array.  This  array  is  a  summary  of  the  entire  enemy 
threat  laydown.  Figures  1  through  3  are  graphic  representations  of  various 
aspects  of  the  data  base. 

STEP  2  is  to  search  the  prioritized  target  list  to  determine  staging 
bases  within  range  of  each  target  with  weapons  effective  against  that  target. 
Staging  bases  within  range  and  with  appropriate  weapons  are  said  to  be 
’’accessible."  Force  status  data  is  part  of  the  accessibility  calculations.  This 
data  includes  current  inventories  of  aircraft  and  weapons  at  each  staging  base. 
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Once  the  data  bases  (including  the  statespace)  have  been  calculated  and 
accessibili ty  has  been  determined,  the  "optimal"  ingress  and  egress  flight  paths 
are  computed.  This  is  STEP  3.  Optimal  routes  are  generated  for  every  target 
from  each  accessible  staging  base.  Performance  data  is  calculated  for  each 
route.  This  data  includes  the  probability  of  survival  and  the  number  of 
aircraft  required  to  attack  the  target  to  reach  the  minimum  damage  threshold. 
This  data  is  then  stored  in  the  data  base. 

Using  accessibility  and  route  performance  data,  FLAPS  determines  which 
staging  bases  should  be  matched  with  each  target.  This  is  the  weapons 
allocation  step,  STEP  4.  In  general,  several  staging  bases  may  be  within  range 
of  a  given  target.  FLAPS  searches  the  route  performance  data  for  each  of  these 
staging  bases  and  determines  which  staging  base  is  most  appropriate.  This 
staging  base  is  then  assigned  to  the  target.  This  is  done  for  each  target,  in 
order  of  priority,  until  either  the  supply  of  weapons  or  aircraft  is  exhausted. 

Optimal  routes  are  generated  using  the  statespace  with  a  very  fast  and 
efficient  dynamic  programming  algorithm  (DPA) .  Routes  are  optimal  in  the  sense 
that  no  other  path  between  the  staging  base  and  the  target  will  have  a  higher 
probability  of  survival.  The  ability  to  quickly  generate  optimal  flight  plans, 
and  change  the  lethality  of  the  enemy  threat  laydown  (change  the  statespace), 
gives  FLAPS  its  power. 

Up  to  this  point,  no  electronic  combat  (EC)  suppression  has  been  applied, 
so  the  penetrating  fighters  may  encounter  significant  threat  danger.  The 
initial  set  of  routes  is  available  to  assist  the  planner  in  deciding  where  to 
put  the  available  EC  suppression  assets.  In  Step  5.  the  planner  applies  the  EC 
suppression  assets  using  a  color  graphics  terminal.  Graphic  displays  and 
reports  help  the  planner  determine  where  EC  suppression  is  required  and  where  it 
will  be  most  effective.  After  the  planner  determines  EC  suppression  application 
points,  FLAPS  updates  the  statespace  to  reflect  the  effects  of  EC  suppression. 
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Then  the  optimal  flight  -paths  are  recalculated.  Typically,  the  routes 
vili  change  in  priority  to  reflect  the  ''high  probability  of  survival  corridors'' 
through  the  FEBA  opened  by  the  EC  suppression  assets.  Again  reports  and  graphic 
displays  show  the  planner  how  effective  this  allocation  will  be  for  improving 
survival  probability  of  the  penetrating  fighters.  The  planner  may  try  several 
types  of  EC  suppression  allocations.  Step  6  involves  generating  the  ATO  which 
gives  the  best  allocation  of  weapons  to  targets,  and  locations  for  the  EC 
suppression  assets.  (The  current  FLAPS  does  not  output  this  data  in  a  MATO 
standard  ATO  format.) 

This  six  step  process  describes  the  overall  structure  of  the  FLAPS 
program  and  its  use.  Descriptions  of  the  underlying  models  are  described  in 
Table  A. 

Table  4.  Subsection  Outline 

Subsection  III.l  Data  Base  Manager  Data 

Bases.  Programs  Inter¬ 
facing  with  FLAPS  Data 
Bases 

Subsection  III. 2  LLTB  Selection  Algorithm 

Subsection  III. 3  Weapons  Allocation 

Algortihm 

Subsection  III. 4 

Subsection  III. 5 


Subsection  III. 6 


Threat  Suppression  Models 

User  Interface 

FLAPS  Graphic  Display 


III.l  DATA  BASE  MANAGER,  DATA  3ASES,  AND  DATA  BASE  INTERFACES 


A  large  amount  of  data  is  needed  to  drive  the  FLAPS  program.  To 
effectively  handle  large,  complicated  data  bases,  SCT  used  a  previously 
developed  data  base  manager.  Vorking  vith  USAFE  personnel,  SCT  acquired  the 
relevant  data  and  constructed  a  base  line  data  base.  An  unclassified  test 
scenario  vas  established  and  vas  used  for  testing,  training,  and  demonstrations. 
In  some  cases,  necessary  data  already  existed  in  U.S.  government  data  bases. 
However,  the  format  of  this  data  vas  not  directly  usable  by  the  FLAPS  data  base 
manager.  These  cases  led  to  development  of  special  data  base  interface 
programs.  Specifically,  a  special  program  was  written  to  interface  DMA  DTED 
data  with  FLAPS.  A  program  to  accept  threat  lethality  data  from  government 
sources  vas  created  as  veil. 

III. 1.1  The  FLAPS  Data  Base  Manager 

An  effective  force  planning  system  requires  a  specialized  data  base 
management  system  (DBMS).  This  DBMS  must  have  data  handling  algorithms  to 
efficiently  accommodate  two  basic  types  of  data,  record-oriented  data  and  large 
matrices.  Such  a  data  base  manager  vas  developed  for  other  automated  mission 
planning  applications  and  integrated  vith  FLAPS.  Record-oriented  data  is 
handled  in  data  base  "tables"  and  large  matrix  type  data  is  handled  in  data  base 
"arrays."  The  fact  that  both  types  of  data  are  handled  efficiently  is  critical 
to  the  success  of  the  FLAPS  program. 

As  a  general  rule,  the  user  interfaces  vith  the  data  bases  through  the 
data  base  tables.  The  user  can  easily  make  changes,  additions,  or  deletions  to 
the  tables.  The  user  may  access'an  individual  record  from  each  table.  For 
example,  the  TG  (target)  table  will  contain  a  record  for  each  target  of  interest 
to  the  planner.  This  table  should  correspond  to  the  current  prioritized  target 
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Many  taoles  ara  static.  They  ara  used  by  the  program  to  describe  fixed 
vehicle  anc  subsystem  models,  and  to  control  the  data  bases  and  graphics  display 
terminal.  These  tables  ara  transparent  to  the  user. 

The  FLAPS  program  automatically  generates  arrays  while  performing  the 
threat  lethality  computations,  routa  generation,  and  target  allocation 
functions.  The  user  cannot  directly  change  the  information  in  arrays.  However, 
the  FLAPS  program  automatically  updates  the  arrays  as  necessary  vhen  the  tables 
are  changed.  One  special  array  is  the  3YTE  (byte  packed  terrain  data)  array. 
This  array  contains  the  DMA  DIED  data  stored  in  a  special  byte  packed  format. 
This  array  is  not  generated  by  the  program  and  must  be  input  into  the  system. 
This  BYTE  array  is  discussed  further  in  Subsection  III. 1.3. 

III. 1.2  The  FLAPS  Data  Base 

To  use  the  FLAPS  program,  the  user  is  responsible  for  data  input  which 
describes  the  current  wartime  situation.  Currently  there  are  no  automated 
interfaces  betveen  FLAPS  and  other  computer  systems  or  data  bases.  (See 
Appendix  A  for  FLAPS  data  base  specification.) 

The  data  base  is  divided  into  two  parts  -  the  tables  and  the  arrays. 

Much  of  the  data  base  is  static  and  will  not  change  as  the  wartime  situation 
changes.  This  includes  the  DMA  DTED  terrain  data  and  certain  tables  which  are 
used  internally  by  the  FLAPS  program  to  control  the  data  base  and  graphics 
display  terminal.  Many  tables  (and  all  but  one  array)  are  generated 
automatically  by  the  program  and  require  no  user  inputs.  The  data  base  tables 
are  the  primary  vehicles  for  access  to  the  data  base. 
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A  brief  summary  of  the  data  base  tables  is  given  in  Table  5.  An  asterisk 
next  to  a  table  name  indicates  a  table  vhich  will  probably  be  frequently  updated 
by  the  user.  (See  Appendix  A  for  detailed  data  base  description.) 


Table  5.  FLAPS  Data  Base  Tables 


Algorithm  Parameters.  This  table  defines  the  dimensions  of 
the  lethality  space  and  other  data  related  to  the  dynamic 
programming  algorithm  and  aircraft  routing. 

Array  Structure.  Initialization  data  for  the  array  data 
bases. 

Current  Processing  Status.  This  table  keeps  track  of  vhich 
algorithms  need  to  be  executed  in  response  to  user  input 
data  base  changes. 

Display  Parameters.  Data  related  to  device  dependent 
graphics  displays. 

Geometry  Coordinate  Tranformations.  Data  related  to  the 
coordinates  of  the  scenario  and  lethality  space. 

LLTR  Locations.  This  user  input  table  defines  the 
positions  of  the  Low  Level  Transit  Routes. 

Node  Parameters.  Data  related  to  the  numbers  of  staging 
bases,  targets,  and  LLTR  points. 

Political  Borders.  Coordinates  of  the  political  borders 
for  the  European  theater. 

ROZ  Restricted  Operating  Zones.  Coordinates  of  current 

restricted  operating  zones. 

SPED  Sortie  Records.  Table  containing  sortie  information, 

including  vaypoints  and  survivability  data. 

STCH  *  Stochastic  Threat  Locations.  Positions  of  imprecisely 
located  threats. 

STGB  *  Staging  Bases.  This  table  contains  the  locations  and 
available  assets  for  each  staging  base  of  interest  in 
the  scenario. 

SUPM  Suppressor  Model  Parameters.  Effectiveness  data  for  the 

EC  aircraft. 

SUPP  *  Suppressor  Positions.  Positions  for  the  EC  aircraft 

during  the  current  planning  cycle.  This  data  is  normally 
input  graphically  by  the  user. 


ALGP 

ASTR 

CURR 

DISP 

GEOM 

LLTR  * 

NODP 

PBOR 
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TH3.T  * 

TMDL 

TSTR 

VEHP 

VEAP 


Software  Switches.  Data  related  :o  fidelity  of  the  terrain 
masxt.ng  algorithm  ana  otner  noaels. 

Target  Positions.  This  taole  contains  the  prioritized 
target  list.  Target  location,  type,  and  minimum  acceptable 
prooability  of  kill  are  included. 

Threat  Positions.  This  table  contains  data  on  threats  vith 
known  locations.  Threat  location,  type,  and  time  entered 
into  the  system  are  included. 

Threat  Models.  Effectiveness  data  on  each  threat  type  is 
contained  in  this  table. 

Table  Structure.  Static  data  which  supports  the  table  data 
base  manager. 

Vehicle  Performance  Parameters.  This  table  contains 
vehicle  performance  data  for  the  attack  aircraft; 
includes  fuel  capacity  and  SCL  dependent  fuel  flow  rates. 

Weapons  Effectiveness  Parameters.  Data  relating  the 
effectiveness  of  each  type  of  weapon  to  each  type  of 
target . 
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Weapons  Free  Zones.  Locations  of  the  theater  dependent 
weapons  free  zones. 


The  data  base  arrays  are  listed  in  Table  6  along  with  a  brief 
description.  Recall  that  the  BYTE  array  must  be  input  into  the  program.  All 
other  arrays  are  automatically  generated  by  the  FLAPS  program. 
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Table  6.  FLAPS  Data  Base  Arrays 


NAME  DESCRIPTION 

ALTG  ARRAY  OF  OPTIMAL  CLEARANCE  ALTITUDES  (NOT  CURRENTLY  USED) 

ALTS  ARRAY  OF  TERRAIN  ALTITUDES  ABOVE  SEA  LEVEL  (NOT  CURRENTLY  USED) 

ARCS  WAYPOINTS  FOR  THE  OPTIMAL  INGRESS  AND  EGRESS  ARCS 

ARPE  PERFORMANCE  DATA  (PS  AND  DISTANCE)  FOR  THE  INGRESS/ EGRESS  ARCS 

BYTE  THE  BYTE  PACKED  DMA  DTED  TERRAIN  DATA  (USER  SUPPLIED) 

CL3D  THREE-DIMENSIONAL  CLOBBER  STATESPACE  (NOT  CURRENTLY  USED) 

ITGC  ARRAY  CONTAINING  TARGET  AND  STAGING  BASE  ACCESSIBILITY  DATA 
ITRC  ARRAY  CONTAINING  EFFICIENT  LLTR  TREES 
MASK  ARRAY  CONTAINING  TEMPORARY  TERRAIN  MASKING  DATA 
NBOX  WINDOWS  INTO  THE  STATESPACE  (USED  TO  COMPUTE  ARCS) 

NLIS  MASTER  LIST  OF  NODES  (STAGING  BASES,  LLTR' S,  AND  TARGETS) 

NPOS  LIST  OF  NODE  POSITIONS  (LONGITUDE  AND  LATITUDE) 

ROUT  ROUTE  PERFORMANCE  (PS  AND  DISTANCE) 

STAT  THE  TWO-DIMENSIONAL  STATESPACE 

SXPE  PERFORMANCE  DATA  FOR  THE  EFFICIENT  LLTR  TREES 

TGUS  TARGET  STATUS  ARRAY  (EFFECTIVENESS  OF  THE  WEAPONS  ALLOCATION) 

TH2D  TWO-DIMENSIONAL  THREAT  DANGER  (NOT  CURRENTLY  USED) 

TH3D  .  THREE-DIMENSIONAL  THREAT  DANGER  (NOT  CURRENTLY  USED) 

TOBS  THREAT  OBSERVABILITY  DATA  (TERRAIN  MASKING  DATA) 

TRPE  INTERMEDIATE  LLTR  TREE  DATA 

3  . 

III. 2  LOW  LEVEL  TRANSIT  ROUTE  (LLTR)  SELECTION 

SCT  modified  the  AUTOPATH  softvare  to  support  the  requirement  for  LLTR 

routing.  An  LLTR  is  a  "safe"  path  used  by  friendly  aircraft.  It  determines  the 
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flight  path  of  a  sortie  from  a  staging  oase  to  the  FZ3A.  Later  in  the  mission, 
the  sortie  viil  use  an  LLTR  to  return  to  the  staging  base  from  the  FEBA. 

An  LLTK  is  comprised  of  one  or  more  Lov  Level  Transit  Segments  pieced 
together.  A  Lov  Level  Transit  Segment  is  a  great  circle  line  formed  by  tvo  Lov 
Level  Transit  Nodes.  Lov  Level  Transit  Nodes  are  navigation  points  vhich  have 
been  selected  because  of  their  ease  of  identification. 

At  any  given-  time,  some  'of  the  Lov  Level  Transit  Segments  are  active 
vhile  the  rest  are  inactive.  Aircraft  flying  in  a  straight  line  be-tveen  the  tvo 
Lov  Level  Transit  Nodes  of  an  active  segment  viil  be  considered  friendly  by 
ground  forces  and  not  fired  upon.  Aircraft  not  on  active  segments  viil  be 
considered  hostile. 

Whether  a  Lov  Level  Transit  Segment  is  active  or  inactive  is  dictated  by 
the  daily  Airspace  Coordination  Order  (ACO).  LLTR  data  from  the  ACO  is  input  to 
FLAPS  through  the  LLTR  table.  Currently  there  is  no  automated  interface  between 
the  ACO  and  FLAPS,  so  the  user  must  update  the  LLTR  table.  The  user  specifies 
vhich  nodes  are  inactive;  vhich  nodes  can  be  used  to  enter  the  LLTR  netvork 
(designated  either  as  entry  or  exit  points);  and  vhich  nodes  are  active 
intermediate  nodes  (i.e.  nodes  vhich  are  active  but  neither  entry  nor  exit 
nodes).  The  connectivity  of  the  netvork  must  be  specified  by  listing  every 
active  node  that  cam  be  reached  from  each  active  node.  Figure  4  depicts  an  LLTR 
netvork  representative  of  FLAPS  processing. 

Once  the  Lov  Level  Transit  netvork  has  been  defined,  FLAPS  finds  the  set 
of  optimal  LLTRs.  This  route  selection  is  accomplished  by  the  application  of  a 
Dijkstra  Shortest  Path  algorithm.  For  each  LLTR  entry  node,  the  algorithm  finds 
the  shortest  path  through  the  LLTR  netvork  to  each  accessible  LLTR  exit  node. 
Note  that  not  every  LLTR  entry  node  is  connected  through  the  netvork  to  every 
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LLTR  exit  node. 


Looking  at  :he  connectivity  of  the  netvork,  accessibility  is 


easily  determined.  Performance  (distance  and  probability  of  arrival)  on  these 
paths  is  stored  in  the  TRPE  array.  The  actual  sequence  of  segments  making  up  a 
path  is  stored  in  the  ITRC  array. 

Since  LLTR  entry  nodes  are  located  near  staging  bases  and  LLTR  exit  nodes 
are  located  near  the  FE3A,  an  out-bound  sortie  vould  fly  tnrougn  the  LLTR 
netvork  by  entering  the  netvork  at  an  entry  node  and  leaving  the  netvork  at  an 
exit  node.  The  sortie  vould  return  to  the  staging  base  by  entering  the  LLTR 
netvork  at  an  exit  node  and  leaving  the  netvork  at  an  entry  node.  The  same 
entry  and  exit  points  may  be  used  for  ingress  and  egress.  However,  the  ingress 
path  may  be  different  from  the  egress  path.  The  actual  paths  are  chosen  in  a 
manner  that  maximizes  probability  of  survival  of  the  sortie  -  subject  to  all 
mission  constraints.  Figure  5  graphically  depicts  optimal  routes  to  LLTR  exit 
nodes. 

After  the  LLTR  route  segments  have  been  processed,  the  target/ staging 
base  accessibility  algorithm  is  executed.  This  is  accomplished  by  looking  at 
which  staging  bases  are  vithin  range  of  each  target.  Route  distance  is 
approximated  at  this  point.  Distance  through  the  LLTR  netvork  (which  is  known 
at  this  time)  is  considered.  However,  because  the  optimal  paths  between  the 
LLTR  exit  points  and  the  targets  have  not  been  calculated  yet,  great  circle 
distance  between  the  LLTR  exit  points  and  the  targets  is  used.  A  152  factor  is 
added  to  this  great  circle  distance  to  approximate  the  increased  distance 
generated  by  maneuvers  to. avoid  these  threats. 
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In  addition  to  range  factors,  veaponeering  is  considered  in  the 
accessibili ty  algorithm.  Only  staging  bases  vith  veapons  and  aircraft  in 
sufficient  numbers  to  be  effective  against  a  target  are  considered. 

III. 3  ATTACK  AIRCRAFT  ROUTING 

3CT  modified  the  AUTOPATH  aircraft  routing  algorithm  in  order  to  meet 
USAFE  specifications.  The  FLAPS  routing  algorithm  creates  and  evaluates 
candidate  sorties  to  each  target  from  each  accessible  staging  base.  Every 
sortie  consists  of  a  target;  staging  base;  round  trip  route  from  target  to 
staging  base;  number  and  type  aircraft  and  veapons. 

Round  trip  routes  are  assembled  from  the  optimal  route  segments  generated 
by  the  Dijkstra  and  Dynamic  Programming  algorithms.  Aircraft  type  is  specified 
for  the  staging  base  in  the  table  STG3.  A  veapons  effectiveness  table, 
resembling  a  condensed  version  of  the  Joint  Munitions  Effectiveness  Manual 
( JMEM ) ,  is  used  to  compute  the  number  of  each  veapon  type  required  to 
successfully  attack  the  target.  The  veapon  carrying  capacity  of  the  aircraft 
then  determines  the  number  of  aircraft  required. 

Often,  many  combinations  of  routes  and  veapon  types  are  possible  for  a 
given  target/staging  base  pair.  The  FLAPS  routing  algorithm  evaluates  these 
combinations  against  an  aircraft  fuel  model  vhich  recognizes  the  dependence  of 
fuel  flov  and  fuel  capacity  on  the  veapon  package  carried.  Those  combinations 
vhich  are  consistent  vith  this  fuel  model  are  considered  feasible  sorties.  Each 
feasible  sortie  has  several  parameters  vhich  describe  its  quality: 

N  *  The  Clumber  of  attack  aircraft 

PS  »  The  round  trip  probability  of  survival 

D1  •  The  route  distance  (NM)  through  the  friendly  side  of  the  FEBA 


D2  =  The  route  distance  (NM)  through  the  enemy  side  of  the  FEBA. 

The  derived  quantity  : 

Q  =  N  *  (  1-PS  +  C1*D1  *  C2*D2  ) 

is  small  for  a  sortie  with  a  small  number  of  aircraft  flying  a  short,  safe 
route.  Conversely,  Q  is  large  for  a  sortie  with  a  large  number  of  aircraft 
flying  a  long,  dangerous  route.  Thus,  Q  is  regarded  as  a  "cost"  associated  with 
the  sortie.  For  each  target/staging  base  pair,  the  FLAPS  routing  algorithm 
selects  the  feasible  sortie  with  minimum  Q  value  and  stores  a  summary  of  it  in 
the  ROUT  array.  The  coefficients  Cl  and  C2  appearing  in  the  definition  of  Q  ar° 
presently  set  at  0.0001  and  0.0003  respectively.  Thus,  the  routing  algorithm 
will  sacrifice  0.01  in  PS,  if  it  can  decrease  D1  by  100  NM  or  D2  by  33.3  NM. 
Figure  6  shows  optimal  ingress  and  egress  flight  paths  from  a  specified  target 
to  all  LLTR  exit  nodes. 

Ill . 4  WEAPONS  ALLOCATION 

The  FLAPS  allocation  algorithm  determines  the  assignment  of  sorties  to 
targets  and  stores  these  assignments  in  an  array  (Array  TGUS)  resembling  an  Air 
Tasking  Order.  This  allocation  process  is  driven  by  the  prioritized  target  list 
given  in  the  Daily  Operations  Order.  It  is  constrained  by  the  weapon  and 
aircraft  inventories  specified  for  each  staging  base. 

The  algorithm  considers  the  targets  in  order  of  decreasing  priority. 

Using  the  routing  algorithm,  each  target  is  assigned  the  "safest"  sorties 
assembled  from  the  inventories  of  remaining  aircraft.  The  safety  criterion  used 
in  this  selection  is  based  on  two  quantities  associated  with  each  sortie  : 

N  *  The  number  of  attack  aircraft 
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PS  =  The  round  trip  probability  of  survival. 

The  derived  quantity  : 

R  =  N  *  (  1-PS  ) 

defines,  in  a  probabilistic  sense,  the  expected  number  of  aircraft  lost  on  the 
sortie.  Therefore,  R  represents  the  total  risk  associated  with  the  sortie.  The 
safest  sortie  is  defined  as  the  one  with  the  minimum  value  of  R.  Thus,  the 
algorithm  will  select  a  sortie  with  N  =  2  and  PS  =  0.35  over  one  with  N  =  4  and 
PS  =  0.9  since 

2*(l-0.85)  <  4*(l-0. 9)  . 

When  aircraft  inventories  are  low,  some  targets  near  the  bottom  of  the 
list  cannot  be  successfully  attacked  with  the  available  aircraft.  The  present 
algorithm  makes  a  single  pass  through  the  target  list  -  no  attempt  is  made  to 
attack  low  priority  targets  at  the  expense  of  the  safety  of  the  sorties  assigned 
to  higher  priority  targets. 

Ill . 5  THREAT  SUPPRESSION 

SCT  implemented  a  method  to  quickly  evaluate  the  effects  of  EC  aircraft 
on  a  given  threat  laydown.  This  permits  the  FLAPS  user  to  quantitatively 
measure  EC  aircraft  ef fee ti veness  and  plan  EC  aircraft  deployments  based  on 
these  results. 

FLAPS  currently  handles  three  different  types  of  EC  aircraft:  EC-130H's 
(Compass  Call),  EF-lll's,  and  F-4  Wild  Weasels.  Each  aircraft  degrades  the 
threat  in  a  different  way.  EC-130s  disrupt  enemy  communications  links,  EF-lll's 
jam  enemy  acquisition  radars,  and  Wild  Weasels  use  HARM  radiation  seeking 
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missiles  to  destroy  enemy  SAM  systems.  FLAPS  maintains  a  seperate  threat 
suppression  model  for  each  of  these  SC  aircraft.  A  model  contains  information 
on  suppressor  effectiveness  against  every  type  of  enemy  threat  system. 

The  FLAPS  threat  suppression  model  vas  developed  as  an  extension  to  the 
existing  AUTOPATH  threat  modeling  approach.  Generic  threat  effectiveness  data 
is  stored  in  the  threat  model  (TMDL)  table.  A  threat  model  (template)  exists 
for  each  threat  and  aircraft  type.  For  example,  a  single  threat  template  might 
contain  effectiveness  data  for  an  SA-6  against  an  F-16.  Threat  ef fectiveness  is 
specified  as  the  negative  log  of  the  probability  of  survival,  per  second  at  each 
up- range/ down- range  and  cross-range  position  within  the  threat's  radius. 
Currently,  both  classified  and  unclassified  threat  models  exist.  The  classified 
models  are  derived  from  TAC  ZINGER  outputs  supplied  by  the 
Survivability/Vulnerability  Information  Analysis  Center  (SURVIAC). 

Information  about  specific  threat  locations  is  contained  in  the  threat 
location  (THRT)  and  stochastic  threat  location  (STCH)  tables.  The  THRT  table 
contains  location  and  threat  type  data  for  every  threat  with  a  known  position. 
The  STCH  table  contains  information  about  mobile  threats  whose  locations  are  not 
precisely  known.  The  threats  with  known  locations  are  terrain  masked  using  DMA 
DTED  terrain  data.  For  each  of  these  threats,  danger  (from  the  threat -model 
table)  is  added  to  all  statespace  cells  which  are  within  the  radius  of  the 
threat  and  which  are  not  terrain  masked.  The  terrain  masking  data  is  stored  on 
disk  for  later  reference.  For  the  mobile  (or  stochastic)  threats,  a  special 
mobile  threat  model  is  applied  which  spreads  the  threat  danger  out  over  the  area 
where  the  mobile  threat  is  believed  to  be  operating.  This  danger  is  also  added 
to  the  statespace. 
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The  lethality  space  then  contains  all  of  the  information  about  the  threat 


laydovn.  The  dynamic  programming  algorithm  may  be  run  at  this  time  and  the 
result  will  be  the  optimal  ingress  and  egress  routes  between  all  accessible 
targets  and  staging  bases.  However,  the  probabilities  of  survival  at  this  stage 
could  be  very  low  -  threat  suppression  has  not  been  applied. 

Threat  suppression  is  accomplished  by  rapidly  adjusting  the  lethality 
space  to  reflect  the  reduced  threat  effectiveness  caused  by  the  EC  aircraft. 

(At  this  point  the  user  may  re-optimi2e  all  routes.)  The  user  inputs  the  . 
locations  of  the  EC  aircraft  (orbit  points)  using  the  graphic  display  terminal. 
The  suppressor  positions  are  stored  in  the  suppressor  position  table  (SUPP). 

The  graphic  display  makes  it  easy  for  the  user  to  quickly  determine  the 
geographic  areas  that  would  benefit  most  by  the  application  of  threat 
suppression  assets.  Figure  7  shows  the  FLAPS  depiction  of  EC  aircraft 
suppression  coverage  areas.  Once  these  areas  are  isolated,  the  user  can  specify 
the  asset  type  and  position  it  by  moving  the  graphics  cursor  to  the  the  desired 
position  using  a  joystick.  This  action  will  create  a  circle  on  the  screen, 
centered  at  the  suppressor  position.  The  circle's  radius  equals  the  range  of 
the  specified  suppressor  type.  The  user  may  repeat  this  process  until  the 
suppressor  assets  have  been  deployed. 
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Another  FLAPS  feature  that  helps  a  user  position  threat  suppression 
assets  is  the  ANALYZE  command  (see  Figure  8).  This  permits  the  user  to  analyze 
a  route  to  determine  which  route  legs  and  threats  are  the  most  dangerous. 
Displaying  threats  producing  the  most  nazard  allows  quick  selection  of  candidate 
areas  for  suppressor  deployment. 


ANAU2--  NUMBER  OF  CRITICAL  POINTS 
NUMBER  OF  THREATS 
ALTITUDE  OF  ROUTE 
TOTAL  PRO 8  OF  SURVIVAL 
TOTAL  DISTANCE  OF  ROUTE 


INDEX 

TIME 

(MIN) 

LATITUDE 

(DMS) 

LONGITUDE 

(DMS) 

HEADING 

(DEG) 

ALT 

(FT) 

LEG  PS 

NODE  NAME 

1 

0.0 

52 

24 

00 

0 

34 

60 

115-75 

197 

1.000 

LAKENHTH 

2 

33.2 

30 

26 

54 

6 

56 

16 

39.73 

197 

0.990 

NC01 

3 

35.6 

50 

26 

59 

7 

26 

33 

46.31 

197 

0.999 

N002 

4 

39.2 

50 

46 

50 

7 

59 

24 

56.62 

197 

0.999 

N003 

5 

42 . 6 

51 

01 

47 

3 

35 

29 

72.33 

197 

0.999 

N004 

6 

46.5 

51 

11 

12  ■ 

9 

22 

43 

133.05 

197 

0.999 

N005 

7 

50.0 

50 

52 

30 

9 

54 

27 

62.99 

197 

0.887 

VAYPOINT 

3 

50.6 

50 

54 

60 

10 

02 

14 

90.00 

197 

0.877 

VAYPOINT 

9 

55.9 

50 

54 

60 

11 

08 

21 

135.53 

197 

0.358 

VAYPOINT 

10 

56.3 

50 

52 

30 

11 

12 

14 

90.00 

197 

0.995 

VAYPOINT 

11 

56.6 

50 

52 

30 

11 

16 

08 

135.50 

197 

0.999 

VAYPOINT 

12 

57.1 

50 

49 

60 

11 

20 

01 

98.38 

197 

1.000 

VAYPOINT 

13 

61.1 

50 

45 

00 

12 

10 

35 

90.00 

197 

0.999 

VAYPOINT 

14 

64.2 

50 

45 

00 

12 

49 

28 

108.69 

197 

0.997 

VAYPOINT 

15 

65.2 

50 

42 

30 

13 

01 

08 

135.38 

197 

0.997 

VAYPOINT 

16 

66.1 

50 

37 

30 

13 

08 

55 

90.00 

197 

1 . 000 

VAYPOINT 

17 

67.6 

50 

37 

30 

13 

28 

22 

136.35 

197 

1.000 

.  VAYPOINT 

18 

70.8 

50 

19 

00 

13 

55 

50 

124.02 

197 

0.985 

PANENSKY 

19 

71.1 

50 

17 

30 

13 

59 

29 

44.80. 

197 

0.989 

VAYPOINT 

20 

71.6 

50 

19 

60 

■  14 

03 

22 

315.38 

197 

1.000 

VAYPOINT 

21 

74.7 

50 

37 

30 

13 

36 

08 

270.00 

197 

0.999 

VAYPOINT 

22  - 

76.8 

50 

37 

30 

13 

08 

55 

315.43 

197 

0.999 

VAYPOINT 

23 

77.7 

50 

42 

30 

13 

01 

08 

288.71 

197 

1.000 

VAYPOINT 

24 

78. 7 

50 

45 

00 

12 

49 

28 

270.00 

197 

0.997 

VAYPOINT 

25 

30.8 

50 

45 

00 

12 

22 

15 

315.48 

197 

0.998 

VAYPOINT 

26 

31.3 

50 

47 

30 

12 

18 

21 

270.00 

197 

0.999 

VAYPOINT 

27 

33.4 

50 

47 

30 

11 

51 

08 

277.25 

197 

0.997 

VAYPOINT 

28 

35.9 

50 

49 

60 

11 

20 

01 

315.53 

197 

0.999 

VAYPOINT 

29 

36.4 

50 

52 

30 

11 

16 

08 

270.00 

197 

1.000 

VAYPOINT 

30 

36.7 

50 

52 

30 

11 

12 

14 

315.55 

197 

0.999 

VAYPOINT 

31 

37.1 

50 

54 

60 

11 

08 

21 

270.00 

197 

0.995 

VAYPOINT 

32 

90.5 

50 

54 

60 

10 

25 

34 

315.61 

197 

0.695 

VAYPOINT 

33 

91.4 

51 

00 

00 

10 

17 

47 

270.00 

197 

0.307 

VAYPOINT 

34 

93.8 

51 

00 

00 

9 

46 

40 

304.30 

197 

0.537 

VAYPOINT 

35 

94.9 

51 

04 

60 

9 

35 

00 

308.86 

197 

0.976 

VAYPOINT 

36 

96.2  • 

51 

11 

12 

9 

22 

43 

252.39 

197 

1.000 

N005 

37 

100. 1 

51 

01 

47 

3 

35 

29 

236.77 

197 

0.999 

N004 

38 

103.5 

50 

46 

50 

7 

59 

24 

226.51 

197 

0.999 

NC03 

39 

107.1 

50 

26 

59 

7 

26 

33 

269.  73 

197 

0.909 

.  N002 

40 

109.5 

50 

26 

54 

6 

56 

16 

296. 72 

197 

0.999 

N001 

41 

142.7 

52 

24 

00 

0 

34 

60 

296.72 

197 

0.990 

LAKENHTH 

97 

60.10 

0.074993 

138.7262 


Figure  3.  Sample  ANALYZE  Command  Output 


Once  the  suppressors  have  been  deployed,  it  is  necessary  to  calculate 
their  effect  on  the  statespace.  For  every  asset  in  the  Suppressor  Position 
table,  the  Suppressor  Model  table  is  consulted  to  determine  its  effectiveness 
against  all  threats  vithin  its  range.  Each  threat  affected  is  removed  from  the 
statespace,  then  its  degraded  threat  is  added  back  in.  For  fixed  threats,  this 
can  be  done  quickly.  Since  FLAPS  stores  all  of  the  terrain  masking  data 
associated  with  a  threat,  it  avoids  recomputing  this  information.  For  mobile 
threats,  the  suppressor  model  reacts  quickly  as  well.  The  mobile  threat 
modeling  approach  was  designed  to  be  compatible  with  the  FLAPS  threat 
suppression  models. 

Each  type  of  threat  suppressor  has  an  associated  capacity.  If  the 
suppressor  is  positioned  with  more  threats  in  its  range  than  it  can  handle,  then 
its  ef fectiveness  is  reduced  by  an  amount  proportional  to  the  excess  number  of 
threats.  Therefore,  a  suppressor  with  a  capacity  of  five  threats,  when  placed 
within  range  of  ten  threats,  will  be  only  one  half  as  effective  (on  a  per  threat 
basis).  However,  the  effects  of  the  suppressor  will  be  spread  out  over  all  ten 
threats. 

After  altering  the  statespace  for  suppression  effects,  the  dynamic 
programming  algorithm  is  re-run  to  find  the  optimal  paths.  This  done,  FLAPS 
re-allocates  the  sorties  to  find  the  best  mission  assignmnent  given  the  new 
threat  laydovn.  If  the  user  is  still  not  satisfied  vith  the  allocation,  it  is  a 
simple  matter  to  quickly  re-position  the  suppressors  and  attempt  to  improve  the 
results.  Figures  9  and  10  represent  graphic  displays  before  and  after 
suppression.  Routing  and  allocation  change  as  a  result. 

III. 6  USER  INTERFACE 

SCT  made  substantial  changes  to  the  AUTOPATH  user  interface  for  USAFE 


figure  9.  Lethal '.ty  Space  and  Routing  -  3efore  Suppression 


J  . 


Figure  10.  Lethality  Space  and  Routing  -  After  Suppression 
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personnel.  These  changes  are  summarized: 


Tailor  the  user  interface  for  force  level  planning 
Reduce  the  number  of  keystrokes;  use  tvo  stroke  COMMONS 
Provide  extensive  on-line  help 
Allow  user  interaction  vith  the  graphic  displays 

Both  the  AUTOPATH  and  FLAPS  programs  are  command  driven.  If  the  user  has 
a  question  about  which  command  is  needed  during  a  run,  he  may  type  HELP.  The 
primary  commands  (used  most  often  by  a  planner)  are  listed  in  Table  7. 


Table  7.  FLAPS  Primary  Command 


FLAPS  PRIMARY  COMMANDS 


CONTROL  COMMANDS: 

HE  OBTAIN  HELP 

RE  '  READ  COMMANDS  FROM  A  FILE 

QU  QUIT  FLAPS  EXECUTION 


DATA  BASE 
AD 
DE 
CH 
SH 


COMMANDS: 

ADD  A  RECORD  TO  THE  DATA  BASE 
DELETE  A  RECORD  FROM  THE  DATA  BASE 
CHANGE  A  RECORD  IN  THE  DATA  BASE 
SHOW  CONTENTS  OR  STRUCTURE  OF  D.B. 


ALGORITHMS  AND  DISPLAY: 

PR  PROCESS  ALL  ALGORITHMS 

DI  PRODUCE  A  GRAPHICAL  DISPLAY 

FI  FIND  AN  OBJECT  GRAPHICALLY 


SUPPRESSION  COMMANDS: 


SE 

SELECT  ROUTE 

AN 

ANALYZE  ROUTE 

LO 

LOCATE  SUPPRESSOR 

SU 

APPLY  SUPPRESSION 

RR 

RE-CALCULATE  ROUTE  WITH 

SUPPRESSION 

RS 

RESTORE  ENVIRONMENT  V/0 

SUPPRESSORS 
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Many  of  the  primary  commands  require  additional  information.  The  user  is 
automatically  prompted  for  this  information  after  entering  the  primary  command. 


All  FLAPS  commands  and  subcommands  require  only  tvo  keystrokes.  Expert  users 
are  accommodated  by  the  user  interface  vith  a  type  ahead  feature.  Suboptions 
and  data  may  be  entered  on  the  same  input  line  as  the  primary  command; 
intermediate  prompts  are  not  issued  by  the  program.  A  number  of  secondary 
commands  are  available  for  program  developers. 

The  user  may  obtain  help  at  any  time  during  program  execution  simply  by 
typing  "HE"  (i.e.  "HELP").  The  user  may  obtain  a  full  description  of  every 
entry  he  must  make  by  putting  FLAPS  in  a  "HELP  ON"  mode.  Under  this  mode,  help 
is  constantly  provided  for  every  input. 

FLAPS  allows  the  user  to  search  the  data  base,  input  suppressor,  ROZ,  and 
VFZ  positions;  and  input/modify  routes  directly  through  the  Tektronix  4115B 
color  graphics  terminal.  This  feature  is  very  convenient  because  FLAPS  provides 
most  planning  information  to  the  user  graphically. 

III. 7  DISPLAYS 

The  AUTOPATH  graphic  displays  have  been  substantially  modified  for  the 
FLAPS  program.  FLAPS  has  been  designed  to  provide  force  planners  vith  a  vide 
variety  of  high  resolution  color  graphic  displays.  By  permitting  the  user  tro 
quickly  and  easily  specify  and  display  any  combination  of  graphic  options,  FLAPS 
enables  the  user  to  readily  assimilate  large  amounts  of  data  encountered  vhen 
planning  at  the  force  level. 
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Great  care  has  been  taken  to  maximize  the  utility  of  the  FLAPS  graphic 
displays.  This  goal  vas  met  by  making  the  selection  of  display  options  user 
friendly.  Every  effort  vas  made  to  minimize  the  number  of  keystrokes  needed  to 
call  up  a  specific  display.  All  display  options  require  typing  at  most  tvo 
characters  for  selection.  The  characters  vere  carefully  selected  to  provide 
meaningful  mnemonics.  Figure  11  is  the  display  prompt  in  FLAPS  vith  the  help 
turned  on. 


ENTER  "SC"  TO  SCALE  PLOTTING  WINDOW 
B  OR  TO  DRAW  GRAPH 

OR  NEXT  SYMBOL  TO  TURN  ON  AN  OPTION 
OR  SYMBOL  FOLLOWED  BY  TO  TURN  OFF  OPTION 
OR  "P"  TO  TURN  OFF  ALL  OPTIONS 
SYMBOL  STATUS  DEFINITION 


A 

AR 

B 

C 

D 

E 

G 

I 

L 

LL 

M 

MA 

RO 

RZ 

ST 

SU 

TG 

V 

WF 


ALTITUDE  CONTOURS 
ARCS 

BOUNDARY  OF  GPHC  WINDOW 
THREAT  CIRCLES 
DANGER  CONTOURS 
ENVELOPES 
GRID  LINES 

INDEXES  (option  not  supported) 

LONGITUDE/ LATITUDE 

LLTRS 

MISSION  (BDRY  ♦  NODES) 

MASKING  (option  not  supported) 

ROUTES 

ROZS 

STAGING  BASES 
SUPPRESSION  CIRCLES 
TARGETS 

CONTROL  VECTORS  (option  not  supported) 

WFZS 


CHOOSE  OPTIONS  or  Scale: 

Figure  11.  FLAPS  Help  Display  -  Prompts 
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Note  that  tnese  are  only  the  major  display  options.  Selecting  many  of 
the  options  would  prompt  the  user  vith  lists  of  suboptions.  For  example,  after 
selecting  "C"  for  threat  circles,  the  user  vould  receive  a  prompt  identifying 
all  of  the  active  threat  types  available  for  display.  The  user  could  then 
specify  display  of  all  threat  circles,  or  any  combination  of  threat  circles. 

Any  time  the  user  instructs  -LAPS  to  draw  a  grapn,  all  selected  options 
will  be  drawn.  The  user  can  cancel  a  specific  option  by  entering  the  option 
prefaced  by  a  minus  sign  (before  giving  the  draw  graph  command).  To  purge  the 
list  of  selected  options,  the  user  enters  a  "P"  before  specifying  the  new  list 
of  display  options.  Table  8  is  a  summary  of  the  major  FLAPS  graphic  display 


Table  8.  FLAPS  Graphic  Display  Options 


ALTITUDE  CONTOURS:  Displays  a  topographic  map  of  the  terrain. 

The  user  specifies  the  MSL  altitudes  desired  for  viewing. 

ARCS:  Displays  either  the  set  of  optimal  paths  from  a  staging  base 

to  all  accessible  LLTR  exits  or  the  set  of  optimal  paths  from  a 
target  to  all  of  its  accessible  LLTR  exits. 

BOUNDARY  OF  GRPHC  WINDOW:  Displays  the  box  around  the  scenario  and 

all  of  the  political  borders  in  the  scenario. 

THREAT  CIRCLES:  Displays  the  envelopes  of  all  fixed  threats  of 

the  selected  type  or  types. 

DANGER  CONTOURS:  Similar  to  terrain  contours,  however  they 

show  lines  of  constant  danger  (probability  of  kill  per  second) 
for  a  given  direction.  These  are  the  best  way  for  the  user  to 
visualise  the  total  threat  laydown. 

ENVELOPES:  Displays  the  boundaries  of  extent  for  any  or  all  of  the 

stochastic  threat  types  in  the  statespace. 

GRID  LINES:  Displays  the  actual  cell  boundaries  used  by  the 

dynamic  programming  algorithm. 

LONGITUDE/ LATITUDE:  Displays  a  labeled  grid  of  longitude  and 

latitude  lines. 

LLTRS:  Displays  all  active  LLTR  nodes  in  the  scenario. 

MISSION:  Displays  all  active  nodes  (staging  bases,  LLTRs  and 
targets)  as  well  as  the  political  and  statespace  boundaries. 

This  is  a  short  cut  to  avoid  having  to  specify  all  of  these 
frequently  desired  options  individually. 

ROUTES:  Displays  any  specific  route  or  set  of  routes  stored  in 

the  SPED  file. 

ROZS:  Displays  all  Restricted  Operating  Zones  in  the  scenario. 

STAGING  BASES:  Displays  all  staging  bases  in  the  scenario. 

SUPPRESSION  CIRCLES:  Displays  circles  centered  where  each 

suppressor  is  positioned.  Each  circle  has  a  radius  equal  to  the 
range  of  the  suppressor  type  at  that  position.  The  user  can 
specify  which  suppressor  types  to  display. 

TARGETS:  Displays  all  active  targets  in  the  scenario. 

WFZS:  Displays  all  of  the  active  Weapons  Free  Zones  in  the 

scenario. 
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The  Tektronix  -*1153  terminal  supports  a  hardware  room  feature  which 
allows'users  to  200m  in  on  .parts  of  the  scenario.  In  addition  to  this  feature, 
FLAPS  allows  the  user  to  rescale  the  display  (the  ''SC"  option)  to  enlarge  part 
of  the  scenario.  The  user  may  rescale  to  the  entire  scenario  (the  "SC" 
suboption),  200m  in  on  the  statespace  (the  "ST"  suboption),  or  input  the 
longitude/ lati tude  coordinates  of  his  desired  window.  FLAPS  also  displays  a 
legend  to  help  the  user  interpret  the  display. 

There  are  many  FLAPS  commands  that  can  be  performed  by  interacting 
directly  with  the  graphics  display.  The  user  can  position  tnreat  suppression 
assets  by  moving  the  graphics  cursor  with  a  thumb  wheel  input  device. 
Furthermore,  he  can  use  the  same  method  to  manually  create  and  manipulate  routes 
and  to  construct  Restricted  Operating  Zones  and  Veapons  Free  Zones.  All  of 
these  capabilities  simplify  the  force  level  planning  task,  of  a  FLAPS  user. 
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SECTION  IV 


SYSTEM  PERFORMANCE 


Speed  of  processing  is  critical  to  automated  force  level  and  unit  level 
planning  systems.  At  the  force  level,  planning  effective  use  of  intelligence 
information  and  force  assets  requires  integrating  and  processing  data  from 
multiple  sources  quickly  enough  to  meet  planning  schedule  constraints,  and 
respond  to  changes  during  the  execution  of  the  plan.  Unit  level  planning  must 
also  be  accomplished  in  a  timely  manner  to  ensure  effective  use  of  weapon  system 
assets . 

The  FLAPS  computer  program  is  designed  to  be  efficient  for  both  force 
level  and  unit  level  planning.  The  algorithms  employed  by  FLAPS  for  data  base 
construction  and  updates  have  been  structured  and  implemented  to  support 
efficient  processing  of  planning  functions.  The  planning  algorithms  for 
routing,  weapons  allocation,  and  EC  aircraft  allocation  have  been  structured  to 
arrive  at  solutions  in  minimal  time. 

This  section  provides  information  in  the  performance  of  the  current  FLAPS 
software  against  the  scenario  described  in  Tables  9  and  10  which  covers  the 
central  European  area. 


Table  9.  FLAPS  Systems  Performance  Test  Scenario 


Geographic  Area: 

Lethality  Space  Area: 

Statespace  Cell  Size: 
Altitude  Levels: 

Planning  Objective: 
Number  of  Staging  3ases: 
Attack.  Aircraft  Type: 

EC  Aircraft  Type: 

Number  of  LLTRs: 


Lat 

-*3 

deg.  N  - 

53 

deg.  N 

Long- 

deg.  E  - 

16 

deg.  E 

La  t 

58 

deg.  N  - 

53 

deg.  N 

Long 

9 

deg.  S  - 

16 

deg.  E 

2.5  r..m  :<  2.5  nm 
200,  500,  1000  ft 
6  OCA  Target 
12 

F-4,  F-16,  F-lil 
EF-111A,  SC-130H,  F-4G 
87 


Table  10.  Threat  Laydovn  for  Test  Scenario 


FIXED  THREATS: 
NUMBER/TYPE  RADIUS 


EU/GCI  THREATS: 
NUMBER/TTPE  RADIUS 


25 

SA-6 

(18.5 

nm  radius) 

7 

SQUATEYE 

(51.2 

nm) 

15 

SA-8 

(  9.0 

nm) 

2 

TALLKING 

(47.6 

nm) 

20 

SA-2 

(20.0 

nm) 

2 

BARLOCK 

(44.4 

nm) 

10 

ZSU-23-4 

(  3.0 

nm) 

2 

3ACKNET 

(42.3 

nm) 

10 

SA-4 

(43.0 

nm) 

2 

FARMGATE 

(42.3 

nm) 

2 

SPOONREST 

(42.3 

nm) 

MOBILE  THREATS: 

15  SA-6 
19  SA-3 


TOTAL:  80  FIXED  SAMs 
34  MOBILE  SAMs 
17  EV/GCI  RADARS 


For  this  test  scenario,  the  objective  is  to  plan  the  attack  of  6  OCA 


targets  using  assets  of  12  potential  staging  bnses  and  EC  aircraft.  Note  that 
the  lethality  space  is  smaller  than  the  geographic  area  for  the  operations. 

This  occurs  when  the  lethality  space  (or  statespace)  is  reduced  to  a  size  which 


covers  the  area  of  the  FEBA  and  the  targetps.  It  is  not  necessary  for  this 
depiction  to  extend  back,  to  all  of  the  staging  bases.  This  geographic  and 
lethality  space  area  was  depicted  in  Figure  1. 

Table  10  lists  the  types  and  numbers  of  threats  considered  in  the  test 
scenario.  The  distinction  made  between  the  fixed  threats,  the  EW/OCI  threat, 
and  the  mobile  threats  is  that  terrain  masking  is  performed  on  the  fixed  and 
EW/CCI  threats,  while  the  mobile  threats  are  not  terrain  masked.  Fixed  threats 
are  those  threats  whose  location  is  known,  while  mobile  threats  are  those  whose 
location  is  not  precisely  known.  Figure  2  is  a  depiction  of  the  threat  laydown 
for  this  scenario. 

System  performance  times  for  two  computer  systems  are  listed  below.  The 
VAX  11/785  is  the  system  used  for  development  purposes  at  SCT's  Palo  Alto 
Headquarters.  Performance  times  are  also  shown  for  SCT's  MicroVAX  II  which  is 
currently  being  tested  in  Palo  Alto.  The  MicroVAX  II  is  an  example  of  a  small 
computer  system  that  could  host  an  operational  version  of  FLAPS  for  force  level, 
and  perhaps  unit  level,  planning. 

Entering  the  commands  NODES,  ACCESS,  ARCS,  ROUTES,  and  ALLOCATE  provides 
the  initial  data  input  and  generates  responses  in  the  times  listed  as  follows: 

SYSTEM  TIMING  DATA  (SECONDS) 

11/785  MicroVAX  II 


CPU 

VALLCLOCK 

CPU 

VALLCL0CK 

NODES 

0.96 

5.67 

2.46 

7.16 

ACCESS 

1.86 

3.55 

4.49 

6.32 

ARCS 

36.88 

46.65 

100.03 

119.64 

ROUTE 

0.64 

1.70 

1.33 

3.20 

ALLOCATE 

0.13 

1.33 

0.17 

0.51 

Entering  SUPPRESS  results  in  calculation  of  suppressor  effects  on  the 
statespace.  The  times  for  this  response  are 

56.05  151.37  11*. IS  272.27 

The  REROUTE  entry  produces  new  routes  that  take  advantage  of  the 
corridors  created  by  suppressor  resources.  Times  for  this  calculation 


39.95 

54.97 

0* .  *3 

166.00 

Input 

RESTORE  to 

regenerate  the  statespac 

e  and  routes 

so  other 

locations  may 

be  considered.  This  requires  the 

times 

Other 

50.81 

entries  and 

110.12 

their  times  are 

123.31 

240.97 

MASK  THREAT 

3.30 

7.04 

7.72 

20.10 

ADD  THREAT 

2.02 

6.62 

3.52 

15.39 

(18  nra) 

MASK  THREAT 

28.30 

68.68 

59.38 

155.57 

ADD  THREAT 

7.76 

20.21 

14.18 

44.55 

(51  nm) 

ADD  STCH 

5.90 

11.70 

11.89 

27.65 

Note  that  the  MicroVAX  II  is  about  one  half  the  speed  of  the  VAX  11/785. 
The  time  required  to  update  the  threat  data  is  critical  for  both  force  and  unit 
level  planning.  A  threat  update  consists  of  masking  the  threat  and  adding  it  to 
the  statespace.  In  Section  VII,  methods  are  discussed  to  reduce  the  time 
required  for  the  MicroVAX  II  to  perform  these  functions. 


Updating  the  data  base  using  a  command  file  is  a  relatively  fast 
operation.  Large  data  base  revisions  can  be  updated  very  rapidly  -  typically  in 
less  than  60  seconds  for  both  machines.  SCT  recommends  accomplishing  major  data 
base  revisions  using  command  files,  since  errors  are  recovered  more  easily. 
Unfortunately,  there  are  no  methods  currently  available  for  automatically 
building  command  files.  These  must  be  entered  manually  by  the  operator.  This 
may  be  a  very  time  consuming  process.  Updating  a  target,  LLTR  node,  or  threat 
requires  one  line  in  a  command  file.  It  will  require  around  30  seconds  or  more 
to  manually  enter  each  line  in  these  command  files. 

A  unit  level  system  will  perform  many  of  the  same  basic  functions  as 
FLAPS.  For  example,  terrain  masking,  threat  analysis,  and  route  generation  are 
necessary  at  the  unit  level.  The  figures  for  the  MicroVAX  II  may  be  used  as  an 
estimate  of  the  performance  of  an  efficient  unit  level  system. 


SECTION  V 


COMPUTER  SYSTEM  CONSIDERATIONS 


There  are  several  computer  system  considerations  related  to  the 
implementation  of  FLAPS  as  an  operational  tool.  At  the  force  level,  there  are 
many  la,rge  data  base  files  vhich  need  to  be  created,  maintained,  and  saved.  The 
creation  and  maintenance  of  this  data  must  be  accomplished  in  a  timely  fashion 
using  minimum  computer  core  resources.  The  need  for  compatibility  between  force 
level  planning  and  unit  level  planning  also  imposes  computer  system 
considerations  on  an  operational  unit  level  system. 

SCT's  goal  has  been  to  keep  computer  core,  disk,  and  run  time 
requirements  as  small  as  possible.  Sometimes  these  goals  conflict.  For 
example,  the  number  of  disk  reads  can  be  reduced,  but  only  at  the  expense  of 
increasing  the  amount  of  core  used.  However,  the  result  is  faster  run  times. 
(See  Section  VII  for  further  discussion.)  The  current  FLAPS  system  has  been 
tailored  to  keep  core  requirements  to  a  minimum.  This  was  done  without 
sacrificing  speed  in  the  dynamic  programming  or  terrain  masking  algorithms. 

V.l  FORCE  LEVEL  REQUIREMENTS 

The  computer  core  requirements  for  the  current  FLAPS  system  are  given  in 


Table  11.  This  should  be  viewed  as  an  estimate  of  the  minimum  computer  core 


required  for  a  force  level  planning  system.  This  data  is  oased  on  performing 
force  level  planning  for  a  geographic  area  covered  by  ATOC  Sembach. 


Table  11.  FLAPS  Computer  Core  Requirements  -  Force  Level 

COMPUTER  CORE  REQUIREMENTS  (BYTES) 

STORAGE  REQUIRED  FOR  OPA  AND  TERRAIN  MASKING:  3,072,044 

STORAGE  REQUIRED  FOR  MOBILE  THREAT  MODEL:  1,000,396 

STORAGE  REQUIRED  FOR  LOCAL  DATA:  351,080 

STORAGE  FOR  DATA  BASE  MANAGER:  262,948 

STORAGE  REQUIRED  FOR  GRAPHIC' DISPLAYS:  143,392 

(not  including  local  memory  vithin  the 
Tektronix  4115B) 

MISC.  STORAGE:  198,013 

CODE:  192,303 

TOTAL  EXECUTABLE  5.221,376 


The  current  FLAPS  executable  requires  approximately  5.2  megabytes  of 
core.  This  is  a  large  number;  however,  it  is  veil  vithin  the  range  of  currently 
available  small  computer  systems.  Note  the  dynamic  programming  and  terrain 
masking  algorithms  require  a  large  amount  of  computer  storage,  if  they  are  to  be 
executed  quickly.  Also  note  the  Tektronix  4115B  color  display  terminal  is  very 
memory  intensive  (although  this  memory  is  contained  locally  vithin  the 
terminal) . 

The  computer  disk  storage  requirements  for  the  current  FLAPS  system  are 
given  Table  12.  This  is  an  estimate  of  the  minimum  computer  disk  storage 
required  for  a  force  level  planning  system  in  the  ATOC  Sembach.  The  list 
contains  only  the  required  data  files.  The  FLAPS  executable,  source  files, 
object  files,  and  command  files  are  not  included.  It  is  not  clear  at  this  time 


TTTT? 


Table  12. 


Data  Base  Tables 


Data  Base  Arrays 


FLAPS  Disk  Storage  Requirements  -  Force  Level 


DISK  FILES 

(BYTES) 

ALGP 

1,024 

ASTR 

6,144 

(  static  ) 

CMDL 

2,560 

(  static 

- 

currently  not 

used 

) 

CURR 

1,024 

DISP 

2,560 

GEOM 

1,536 

LLTR 

25,600 

NODP 

1,024 

PBOR 

49,664 

(  static 

) 

ROZ 

3,072 

SPED 

269,824 

STCH 

22,016 

STGB 

4,096 

SUPM 

5,632 

(  static 

) 

SUPP 

2,560 

SUCH 

1,024 

(  static 

) 

TG 

2,048 

THRT 

28,672 

TMDL 

77,312 

(  static 

) 

T5TR 

446 , 464 

(  static 

) 

VEHP 

4,096 

(  static 

) 

UEAP 

9,216 

(  static 

) 

UFZ 

2,048 

ALTG 

9,728 

(  static 

_ 

currently  not 

used 

) 

ALTS 

355,328 

ARCS 

38,400 

ARPE 

19,456 

BYTE 

6,843,392 

(  static 

) 

CL3D 

9,728 

(  static 

- 

currently  not 

used 

) 

ITGC 

19,456 

ITRC 

19,456 

MASK 

384,000 

NBOX 

19,456 

NL IS 

19,456 

NPOS 

19,456 

ROUT 

19,456 

STAT 

355,328 

SXPE 

19,456 

TGUS 

19,456 

TH2D 

9,728 

(  static  - 

currently  not 

used  ) 

TH3D 

1,027,584 

T0BS 

662,528 

TRPE 

19,456 

TOTAL 

10,859,520 

vhich  files  (besides  che  executable)  vill  be  required  on  an  operational  system. 
Data- files  vhich  are  static  (or  not  currently  being  used)  are  noted  as  such. 

The  10. S  megabytes  of  disk  storage  reflect  the  current  test  scenario. 
Increasing  the  number  of  threats,  targets,  staging  bases,  etc.,  vill  increase 
the  amount  of  necessary  storage.  Hovever,  the  volume  of  the  largest  arrays, 
3YTE  and  TH3D,  does  not  depend  on  the  number  of  threats  or  targets.  It  depends 
only  on  the  size  of  the  scenario  and  the  statespace  cells. 

As  changes  are  made  to  the  system  to  make  it  operational,  these 
requirements  may  alter  substantially.  BYTE  and  TH3D  are  the  largest  disk  files 
used  by  FLAPS.  The  current  byte  packed  terrain  file  (BYTE)  is  for  the  region  8 
to  16  degrees  east  longitude  and  48  to  54  degrees  north  latitude.  If  a  larger 
terrain  data  file  is  needed  in  the  future,  then  the  BYTE  file  vill  expand  as 
veil.  Currently  there  is  only  one  TH3D  file.  If  it  becomes  necessary  to  build 
multiple  statespaces  for  the  different  airframes,  then  multiple  TH3D  files  vill 
follov.  Also  the  current  TH3D  file  contains  danger  at  only  three  altitudes 
(200,  500,  and  1000  feet).  If  more  altitudes  are  required,  then  this  file  vill 
become  larger.  In  the  current  test  scenario  there  are  about  one  hundred  fixed 
threats.  Terrain  masking  information  for  these  threats  is  stored  in  the  T0BS 
array.  If  the  number  of  fixed  threat  sites  increases  dramatically,  then  this 
file  could  become  larger  than  both  the  BYTE  and  TH3D  files. 

The  FLAPS  program  is  numerically  intensive  and  requires  frequent  access 
to  the  hard  disk  drive.  The  computer  host  for  FLAPS  has  to  be  selected  vith 
these  characteristics  in  mind.  A  floating  point  processor,  an  efficient  data 
bus,  fast  memory  access,  and  fast  disk  access  are  all  necessary  if  the  FLAPS 
program  is  to  run  efficiently.  Small  computer  systems  that  meet  these 
requirements  are  currently  available. 
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V.  2  UNIT  LEVEL  REQUIREMENTS 

FLAPS  is  very  similar  to  the  system  that  could  be  used  at  the  unit  level 
for  detailed  mission  planning.  The  basic  functions  of  terrain  masking,  threat 
modeling,  and  route  generation  are  inherent  to  such  a  system.  Because  these 
functions  consume  the  most  core  and  disk  space,  it  is  possible  to  use  the  FLAPS 
computer  system  can  be  used  as  a  baseline  for  the  requirements  of  a  unit  level 
system. 


SCT  feels  that  the  major  difference  between  a  unit  level  system  and  a 
force  level  system,  like  FLAPS,  is  the  size  of  the  scenarios.  Since  tactical 
aircraft  have  limited  range,  a  unit  level  system  does  not  need  the  capacitiy  to 
look  at  very  large  scenarios.  The  core  and  disk  requirements  already  listed  can 
be  considered  upper  bounds  for  unit  level  needs. 

Reducing  the  scenario  size  for  the  unit  level  system  would  reduce  the 
core  requirements.  Specifically,  the  core  required  to  execute  the  dynamic 
programming  algorithm  and  the  terrain  masking  algorithm  could  be  reduced  by 
about  1.5  megabytes.  Therefore,  SCT  believes  a  unit  level  system  could  be 
designed  to  required  between  3  and  3.5  megabytes  of  core.  The  disk  storage 
requirements  would  probably  be  102  to  252  smaller  than  those  for  the  force  level 


system. 


SECTION  VI 


OPERATIONAL  IMPLEMENTATION 


The  current  FLAPS  system  has  effectively  demonstrated  the  capability  of 
an  automated  force  planning  system  -  the  goal  of  this  effort.  Hovever, 
significant  capabilities  need  to  be  added  to  make  the  system  operational.  These 
capabilities  include  real  time  interfaces,  data  base,  and  operative 
functionality. 

VI . 1  INTERFACES 

The  most  obvious  problem  vith  the  current  system  is  the  lack  of  real  time 
interfaces  vith  the  key  data  bases  relevant  to  mission  planning.  Table  13  lists 
these  data  bases. 


Table  13.  FLAPS  Key  Data  Bases 

Real  time  threat  location  data  (LOCE  interface) 
Prioritized  target  list  (D00  interface) 

LLTR  data  (ACO  interface) 

Force  status  information 


Ail  of  this  data  currently  exists,  or  viil  exist,  in  the  NATO  ATOCs. 

Real  time  threat  data  is  available  through  tne  L01E  system.  The  D00,  ACO,  and 
force  status  data  are  available  thrcugh  the  EIFEL  system.  This  data  will  need 
to  interface  vith  the  FLAPS  system.  Dne  approach  to  providing  such  an  interface 
is  through  simple  file  tranfers.  This  is  a  low  risk  and  low  cost  approach. 

LOCE  and  EIFEL  data  could  be  stored  as  ASCII  files  on  their  host  computers. 

'Jhen  appropriate,  the  planner  could  tranfer  these  files  to  the  FLAPS  system 
computer  host.  The  ASCII  file  format  will  reduce  data  compatibility  problems. 

An  interface  program,  residing  on  the  FLAPS  host  computer,  would  read  these 
files  and  produce  FLAPS  command  files.  The  FLAPS  data  base  could  then  be 
updated  by  reading  these  files.  Currently,  FLAPS  command  files  are  simple  ASCII 
files  while  the  actual  FLAPS  data  base  is  not. 

A  more  sophisticated  system  would  be  based  on  real  time,  automatic  data 
base  updates.  This  would  require  a  real  time  operating  system  on  the  FLAPS  host 
computer,  real  time  communications  links  between  computers,  and  sophisticated 
data  management  software.  Designing  such  a  system  would  be  a  major  undertaking 
that  must  be  included  in  future  plans. 


71.2  DATA  BASES 

The  data  bases  listed  above  are  highly  dynamic.  Other  data  bases  are 
also  critical  to  the  planning  system,  but  they  change  much  less  frequently. 


These  data  bases  include: 


Table  14.  FLAPS  Dynamic  Data  Bases 


DMA  DTED  terrain  data 

JMEM  compatible  data  base  for  veaponeering 
Threat  models  consistent  vith  the  LOCE  data 

A  terrain  data  base  covering  much  of  central  Europe  is  in  the  current 
FLAPS  data  base.  If  the  current  terrain  (BYTE)  file  is  not  large  enough,  then  a 
new  file  could  be  generated  at  lov  cost.  A  JMEM  compatible  data  base  is  not 
currently  contained  in  the  FLAPS  data  base.  The  veaponeering  methodology  in  the 
current  FLAPS  program  is  compatible  vith  JMEM;  however,  a  data  base  compatible 
vith  JMEM  has  not  been  generated  to  date.  A  data  base  for  a  limited  number  of 
target  types  (say  10  or  20)  could  be  created  for  testing  purposes  at  lov  cost.. 

TAC  ZINGER  threat  effectiveness  data  for  tactical  SAM  and  AAA  systems  has 
been  provided  using  SURVIAC.  SCT  has  written  and  tested  a  program  (SKIPPK)  to 

convert  this  data  into  a  form  compatible  vith  FLAPS.  Recent  discussions  vith 

USAFE  personnel  familiar  vith  the  LOCE  system  do  not  clarify  vhether  these 

threat  templates  will  be  very  useful  in  their  current  form.  LOCE  vill  provide 

precise  information  on  EW  and  GCI  radars;  however,  exact  SAM  and  AAA  positions 
vill  probably  not  be  available.  If  this  is  the  case,  then  threat  templates 
which  relate  EV/GCI  location  and  coverage  vith  SAM  and  AAA  coverage  vill  have  to 
be  developed.  Some  modifications  to  the  SKIPPK  program  vill  be  necessary.  This 
vill  be  neither  a  high  risk  nor  high  cost  change.  The  basic  FLAPS  approach  is 
not  changed.  ^ 

VI. 3  FUNCTIONAL  CAPABILITY 

Vith  the  fixed  and  static  data  bases  listed  previously.  SCT  feels  the 
current  FLAPS  program  vould  be  an  excellent  tool  for  ATOC  planners.  A  fully 
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operational  system  vill  require  increasea  functional  capability  in  the  areas 
listed  in  Table  15. 

Table  15.  FLAPS  Areas  Requiring  Increased  Capabilities 

Detailed  consideration  of  operational  scheduling  constraints, 

including  veather,  tankers,  and  aircraft  turn  times 

ATO  and  ATM  formated  output 

EIFEL  interface  to  output  ATO 

Menu  driven  user  interface 

All  of  these  issues  are  being  addressed  in  the  FULL  FLAPS  effort  and  vill 
not  be  discussed  here. 


SECTION  VII 


CON.  ' dSIONS  AND  RECOMMENDATIONS 

The  FLAPS  effort  described  in  this  report  has  effectively  demonstrated 
the  automated  force  planning  concept.  This  effort  has  provided  a  valuable  tool 
for  defining  requirements  of  the  operational  force  planning  system  (FULL  FLAPS), 
as  well  as  defining  requirements  for  data  base  interfaces  at  the  ATOC  level. 

SCT  feels  that  the  FULL  FLAPS  effort,  currently  in  the  planning  stages,  will 
produce  a  dynamic  and  responsive  force  planning  system.  Certain  issues  not 
addressed  directly  in  the  FULL  FLAPS  effort  are  discussed  below.  SCT  feels  that 
these  issues  are  important  to  the  long  run  success  of  both  force  and  unit  level 
planning  systems. 

VII. 1  FORCE  AND  UNIT  LEVEL  COORDINATION 

Coordination  between  the  force  and  unit  levels  is  critical  for  mission 
success  in  the  European  theater.  The  data  and  strategy  used  by  the  force  level 
planner  must  be  available  to  the  unit  level  planner.  Without  this  interface 
there  is  a  significant  chance  the  plan  developed  at  the  force  level  will  be 
severely  degraded.  For  example,  the  high  probability  of  survival  corridors  may 
not  be  used  by  the  attack  aircraft.  This  will  occur  if  the  unit  level  planners 
do  not  understand  (or  do  not  have  confidence  in)  EC  aircraft  allocation. 


Fortunately,  it  is  possible,  to  have  up  to  date  planning  data,  powerful 
planning  computers,  and  graphics  terminals  at  the  unit  level.  Critical  planning 
data  will  be  available  through  LOCE  and  the  EIFSL  network.  Unit  level  planning 
computer  systems  are  under  development.  SCT  strongly  recommends  that  every 
possible  effort  be  made  to  insure  the  force  and  unit  level  systems  are 
compatible.  While  each  planning  system  has  special  requirements,  maintaining  a 
common  technical  approach  for  both  systems  will  guarantee  successful  planning 
results. 

VII. 2  ADDITIONAL,  RESEARCH  FOR  KEY  MATHEMATICAL  MODELS 

Additional  research  must  be  performed  to  support  improved  threat  and  EC 
effectiveness  models.  While  considerable  data  currently  exists,  only  limited 
amounts  are  directly  applicable  to  force  and  unit  level  planning.  Force  and 
mission  planning  demands  fast  response  time  and  the  rapid  consideration  of  many 
potential  flight  paths.  Traditional  trajectory  analysis  approaches,  including 
detailed  monte  carlo  simulations,  are  not  feasible.  Optimal  path  algorithms  as 
used  in  FLAPS  are  available,  and  can  produce  very  good  flight  plans  in  minimal 
time.  However,  the  threat  data  needed  to  support  these  algorithms  is  currently 
very  limited.  A  different  type  of  data  is  needed  for  these  models.  Threat 
models  used  by  optimal  path  algorithms  should  accurately  include  the  effects  of 
enemy  command,  control,  communication  systems,  saturation  effects  (many  attack 
aircraft  saturating  the  defenses),  and  weather.  These  effects  are  difficult  to 
model.  It  may  even  be  impossible  to  model  these  effects  exactly  in  a  force  or 
mission  planning  system.  However,  it  should  be  possible  to  develop  such  models. 
They  must  approximate  the  data  generated  by  more  detailed  simulations  and 
support  fast  flight  path  routing  algorithms. 


The  same  is  true  for  threat  suppression.  EW  effectiveness  models  should 
be  developed  to  show  the  effects  of  standoff  and  onboard  self  protection 
jamming,  and  degraded  enemy  command  and  control.  These  models  should  be 
compatible  with  the  FLAPS  approach.  Such  models  would  exhibit  fast  execution 
and  compatibility  with  the  threat  models  described  above.  Again,  it  may  be 
necessary  to  sacrifice  some  accuracy  in  order  to  meet  these  goals.  Given  the 
critical  need  for  force  and  mission  planning  aids,  the  payoff  from  this  research 
would  be  substantial. 

VII. 3  ROUTING  ALGORITHM  RESEARCH 

The  dynamic  programming  algorithm  used  in  FLAPS  is  very  fast  and  produces 
minimum  threat  exposure  routes.  However,  the  applicability  of  this  algorithm  at 
the  unit  level  is  questionable  given  the  aircraft  inflight  performance  and 
navigation  constraints.  The  current  algorithm  tends  to  produce  routes  with  many 
turns,  some  of  which  can  be  quite  sharp.  These  routes  may  be  unacceptable  to 
the  pilot. 

Other  approaches  under  consideration  by  SCT  include  an  algorithm  which 
would  only  consider  turns  at  predefined  "delta"  or  navigation  points.  The 
optimum  path  would  be  constructed  by  connecting  the  best  possible  sequence  of 
delta  points.  Probability  of  survival  would  be  maximized  while  meeting  fuel, 
navigation,  and  turn  constraints.  Such  an  algorithm  could  be  developed  with  low 
cost/risk  factors. 

Other  improvements  to  the  routing  algorithm  could  be  made  in  the  area  of 
terrain  following/ terrain  avoidance  (TF/TA)  and  optimal  clearance  settings.  The 
original  AUTOPATH  algorithm  contained  an  option  for  altitude  optimization. 
However,  this  algorithm  tended  to  produce  frequent  altitude  changes.  For  this 
reason,  the  option  was  not  included  in  the  FLAPS  program.  An  effort  to  improve 
this  model  would  be  valuable. 


VII. 4  USE  OF  FLAPS  AT  HIGHER  COMMAND  LEVELS 


The  current  FLAPS  program  vould  have  valuable  applications  at  NATO 
command  levels  above  the  ATOC.  At  the  AArCE  level,  FLAPS  could  be  used  to  plan 
the  Air  Directive.  At  the  ATAF  level,  FLAPS  could  be  used  to  assist  planners 
selecting  LLTR's  and  allocating  EC  and  attack,  assets.  Modifications  to  the 
program  vould  probably  be  necessary  to  support  these  functions. 

A  FLAPS  system  could  also  be  used  at  the  ATOC  to  support  current 
operations  personnel.  Because  FLAPS  can  rapidly  compute  attack  aircraft 
allocations,  it  lends  itself  ideally  to  constructing  ATM's  in  response  to 
changes  in  targets,  available  assets,  veather,  'and/or  threats. 

Finally,  FLAPS  is  an  excellend  training  aid  for  a  facility  like  the 
Varrior  Preparation  Center  (VPC).  FLAPS  could  be  used  to  construct  ATO's  during 
training  exercises  or  train  ATO  planners. 

VII. 5  SMALL  COMPUTER  IMPLEMENTATION 

Small  computer  implementation  of  FLAPS  for  force  and  unit  level  planning 
is  a  stated  need  for  USAFE.  SCT  has  begun  to  evaluate  small  computer 
architecture  as  it  relates  to  FLAPS  processing.  SCT  pruchased  the  MicroVAX  II 
in  support  of  this  effort. 

A  specialized  version  of  the  FLAPS  program  has  been  developed  to  take 
maximum  advantage  of  the  available  memory  on  the  MicroVAX  II.  This  reduces  the 
number  of  time  consuming  disk  accesses  Tor  certain  tasks.  The  program  is 
refered  to  internally  as  "Tuned  FLAPS."  To  date,  the  effort  has  concentrated  on 
the  terrain  masking  and  threat  lethality  computations.  System  performance  data 
comparing  this  program  with  the  current  FLAPS  program  is  given  in  Table  16. 


Table  16.  FLAPS  Comparative  System  Performance  Data 
SYSTEM  PERFORMANCE  (VALLCLOCK  SECONDS) 


FUNCTION 

CURRENT 

FLAPS 

TUNED  FLAPS 

VAX  11/785  MICROVAX  II 

MICROVAX  II 

MASK  18.5  nm  THREAT 

7 

20 

6 

ADD  18.5  nm  THREAT 

7 

15 

12 

MASK  51.2  nm  THREAT 

69 

156 

44 

ADD  51.2  nm  THREAT 

18 

43 

23 

MASK  ALL  THREATS 

1922 

3671 

1549 

ADD  ALL  THREATS 

902 

2143 

1219 

(using  the  test  scenario 
described  in  Section  IV) 

The  above  table  suggests  that  the  terrain  masking  step  can  be  speeded  up 
considerably  by  using  computer  memory  mote  efficiently.  A  useful  force  or  unit 
level  planning  system  must  be  able  to  update  its  threat  data  base  very  rapidly. 
Further  research  in  this  area  may  prove  extremely  useful. 


APPENDIX  A 


FLAPS  DATA  BASES 


There  are  two  types  of  data  structures  in  FLAPS:  Tables  and  Arrays. 
Tables  are  record-oriented  data  structures  which  are  under  the  direct  control  of 
the  user.  Arrays  are  matrix-oriented  data  structures  which  are  created  and 
maintained  by  the  FLAPS  software.  Typically  arrays  contain  a  much  greater 
quantity  of  data  than  tables. 

A. 1  TABLES 

There  are  22  tables  defined  in  FLAPS,.  The  names  and  descriptions  of  the 
tables  are  given  below.  Those  tables  which  require  input  from  the  user  are 
marked  with  an  asterisk.  The  remaining  tables,  while  important,  will  only 
occasionally  be  of  interest  to  the  planners.  Many  of  these  tables  are  created 
when  the  data  base  is  first  initialized,  and  then  never  change.  These  tables 
include  TSTR,  ASTB,  and  SVCH. 


NAMES  AND  DESCRIPTIONS  OF  TABLES' 


TSTR 

TABLE  STRUCTURE 

ASTR 

ARRAY  STRUCTURE 

ALGP 

ALGORITHM  PARAMETERS 

CURR 

CURRENT  STATUS 

DISP 

DISPLAY  PARAMETERS 

GEOM 

COORDINATE  TRANSFORMATIONS 

LLTR 

★ 

LLTR  NODE  PARAMETERS 

NODP 

NODE  PARAMETERS 

?BOR 

POLITICAL  BORDERS 

ROZ 

RESTRICTED  OPERATING  ZONES 

SPED 

SORTIE  RECORDS 

STCH 

* 

STOCHASTIC  REGIONS 

STGB 

•k 

STAGING  BASE  PARAMETERS 

SUPM 

SUPPRESSION  MODELS 

SUPP 

■x 

SUPPRESSOR  TYPE 

SVCH 

VARIOUS  SVITCHES 

TG 

★ 

TARGET  PARAMETERS 

THRT 

* 

FIXED  THREAT  LOCATIONS 

TMDL 

THREAT  MODELS 

VEHP 

VEHICLE  PARAMETERS 

VEAP 

WEAPON  PARAMETERS 

VFZ 

WEAPON  FREE  ZONES 

The  first  record  of  each  table  is  a  header  record.  This  record  contains 
information  used  by  the  file  management  software,  and  is  uninteresting  to  the 
user.  Data  which  is  stored  in  a  table  begins  in  record  2.  Some  tables,  such  as 
the  Algorithm  Parameter  (ALGP)  Table  have  only  two  records.  Other  tables,  such 
as  the  Threat  Location  (THRT)  Table  have  many  records.  Vi  thin  a  table,  the 
structure  of  each  record  is  the  same;  that- is,  the  records  are  all  of  identical 
length  and  are  organized  into  the  same  sequence  of  items.  For  example,  the 
following  excerpt  shows  the  contents  of  the  first  two  and  the  last  record  in  the 
threat  location  table.  Each  record  (except  the  header  record)  corresponds  to  a 
single  fixed  threat.  The  same  information,  organized  in  the  same  fashion, 
exists  for  each  threat. 


CRSHOW  —  RECORD 


2 


IDV0RD-S001 


ID  =  S001 

ITYP=  SA-11 

XTH  =  1 . 2082E+01  5.0615E+01  1.0000E+01 
PEX  =  1 . OOOOE+OO 
I DC  =  505291337 

IDM  *  505291337 

CRSHOW  —  RECORD  3  IDW0RD-S002 

ID  =  S002 

ITYP=  SA-11 

XTH  =  1 . 2197E+01  5.0427E+01  1.0000E+01 
PEX  *  1. OOOOE+OO 
I  DC  =.  505291337 

IDM  =  505291337 

CRSHOW  —  RECORD  52  IDWORD=S051 

ID  *  S051 

ITYP=  SA-1B 

XTH  =  1.7200E+01  4.8500E+01  1.0000E+01 
PEX  =  1. OOOOE+OO 
I DC  =  505291337 

IDM  -  505291337 


The  Threat  Location  Table  has  six  items.  Each  item  has  a  one  to  four 
character  name  (ID,  ITYP,  etc.).  Notice  that  some  items,  such  as  ID,  correspond 
to  one  element  of  data;  while  other  items,  such  as  XTH,  correspond  to  more  than 
one  element.  Each  item  is  designated  as  character,  integer  or  real.  Mixed  data 
types  may  not  be  associated  with  a  single  item. 

The  item  structure  of  a  record  is  very  useful  for  manipulating  the 
contents  of  the  record.  The  first  item  in  each  record  is  the  ID  of  the  record. 
The  ID  is  of  character  data  type.  A  record  may  be  accessed  by  its  integer 
record  number  or  by  its  character  ID.  The  use  of  these  two  methods  of  accessing 
a  record  are  discussed  under  the  various  data  base  commands  in  section  2. 
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The  last  tvo  items  of  each  record  in  every  one  of  the  FLAPS  tables  are 
the  creation  date"  (IDC)  and  modification  data  (IDM)  of  the  record.  These  tvo 
items  are  not  under  the  control  of  the  user:  he  neither  specifies  their  values 
nor  can  he  change  them.  Hovever.  he  can  use  the  SHOW  command  to  see  what  their 
values  are.  They  are  formatted  as  integer  values  in  order  that  dates  may  be 
easily  compared  to  see  vhich  one  is  later.  The  format  is  'ymmddhhmm'.  Thus, 
for  example,  the  last  record  in  the  Threat  Location  Table  above  vas  created  and 
modified  at  13:37  on  May  29,  1985  (IDC  =  IDM  =  505291337). 


A. 1.1  THE  TABLE  STRUCTURE  (TSTR)  TABLE 


The  Table  Structure  Table  contains  the  information  which  defines  the 
structure  of  every  other  FLAPS  table.  Each  record  in  TSTR  describes  one  of  the 
other  FLAPS  tables.  TSTR  is  created  by  the  program  during  a  special 
initialization  run  in  which  the  file  ZDEFINE.DAT  is  read.  The  current  version 
of  ZDEFINE.DAT  is  included  in  Appendix  A.  This  run  is  invisible  to  the  user. 
The  user  should  never  attempt  to  ADD,  DELETE,  CHANGE  or  COPY  the  TSTR  table. 

The  structure  of  the  Table  Structure  Table  is  shown  below.  This  excerpt 
may  be  recreated  by  typing  "SHOW  TSTR  HELP". 


TSTR  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

title 

NAMT 

CH04 

1 

1 

TABLE  NAME  >•>', 

NXRC 

INT 

1 

2 

MAXIMUM  RECORDS  i 

IAFT 

INT 

1 

3 

EFFECT  OF  CHANGING  TABLE 

NIT 

INT 

1 

4 

NUMBER  OF  ITEMS  •>' 

ITIT 

CH24 

1 

5 

TITLE  OF  TABLE  -V  '.- 

NAMI 

CH04 

80 

11 

ITEM  NAMES 

ITYP 

CH04 

80 

91 

ITEM  TYPES 

ISIZ 

INT 

80 

171 

ITEM  SIZES  i  -'i-- 

ITTL 

CH24 

80 

251 

TITLE  OF  ITEMS 

IDEF 

INT 

80 

731 

DEFAULTABLE  ITEM  FLAG 

IACC 

INT 

80 

811 

ITEM  ACCESS  CUSS  •  -V  ] 

IEDT 

INT 

80 

891 

ITEM  EDIT  TYPE  V  -"N 

PARI 

REAL 

80 

971 

ITEM  LOWER  LIMIT  ■*!>*'; 

PAR2 

REAL 

80 

1051 

ITEM  UPPER  LIMIT  ^  V- 

IAFI 

INT 

80 

1131 

EFFECT  OF  CHANGING  ITEM  f-' ' ' 

IDC 

INT 

1 

1211 

CREATION  DATE 

IDM 

INT 

1 

1212 

MODIFICATION  DATE  o  .-' 

The  first  item  is  the  record  ID  —  it  is  the  same  as  the  name  of  the 


table  vhich  this  record  describes  ('AS7R',  'ALGP',  etc.)-  The  next  item  is  the 
maximum  number  of  records  allovea  in  the  table,  including  the  header  record. 

The  affect  code  is  an  integer  vhcse  meaning  is  described  in  the  section  on  the 
CURR  table  (3.1.4).  Then  comes  the  number  of  items  in  the  table  and  a  24 
character  title  for  the  table.  The  next  ten  items  are  each  of  size  30,  and 
describe  the  individual  items  vithin  the  table.  Thus  the  number  of  items  in  any 
table  must  not  exceed  80.  NAMI  is  the  one  to  four  character  name  of  the  items; 
ITYP  is  the  data  type  ('REAL',  ' INT  '  or  'CHnn',  for  a  character  item  vhose 
element  length  is  nn  characters).  ITTL  is  a  24  character  description  of  the 
item.  IDEF  is  not  currently  implemented.  IACC  has  the  value  of  0  for  almost 
all  items,  but  has  the  value  of  -5  for  those  fev  items  vhich  are  not  accessible 
to  the  user  in  ADD  or  CHANGE  commands.  IEDT,  PARI,  PAR2  and  IAFI  are  not 
currently  implemented. 
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A. 1.2  THE  ARRAY  STRUCTURE  (ASTR)  TABLE 


The  Array  Structure  Table  contains  the  information  which  defines  the 
structure  of  every  FLAPS  array.  Each  record  in  ASTR  describes  one  of  the  FLAPS 
arrays.  ASTR  is  created  by  the  program  during  a  special  initialization  run,  in 
which  the  file  ZDEFAR.DAT  is  read.  This  run  is  invisible  to  the  user.  The 
current  version  of  ZDEFAR.DAT  is  included  in  Appendix  B.  The  user  should  never 
attempt  to  ADD,  DELETE,  CHANGE  or  COPY  the  ASTR  table. 

The  structure  of  the  Array  Structure  Table  is  shown  below.  This  excerpt 
may  be  recreated  by  typing  "SHOW  ASTR  HELP". 


ASTR  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

NAMA 

CH04 

1 

1 

ARRAY  NAME 

NXRC 

INT 

1 

2 

MAX  NUMBER  OF  RECORDS 

ITIT 

CH24 

1 

3 

TITLE  OF  ARRAY 

IDC 

INT 

1 

9 

RECORD  CREATION  DATE 

IDM 

INT 

1 

10 

RECORD  MODIFICATION  DATE 

:  first 

item  is 

the 

record 

ID  —  it  is  the  same  as  the 

array  which  this  record  describes  ('ARCS',  'ARPE',  etc.).  The  next  item  is  the 
maximum  number  of  records  allowed  in  the  array,  including  the  header  record. 
ITIT  is  a  24  character  title  for  the  array. 


A- 7 


A.  1.3  ALGORITHM  PARAMETERS  ( ALGP)  TABLE 


The  Algorithm  Parameters  Table  defines  the  scenario  and  the  statespace. 
This  includes  the  geographic  region  over  which  the  scenario  is  defined,  and  the 
statespace  quantization  level  (cell  size).  Record  2  of  this  table  must  be 
properly  defined  before  any  processing  starts. 


A. 1.3.1  ALGP  TA3LE  USAFE  - 


The  structure  of  the  ALGP  table  is  shown  below.  This  table  can  be 
created  by  typing  "SHOW  ALGP  HELP". 


ALGP  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH04 

1 

1 

ID  «  ALGP 

DELE 

REAL 

1 

2 

LONGITUDE  GRID(NM) 

DELN 

REAL 

1 

3 

LATITUDE  GRID(NM) 

XMIN 

REAL 

1 

4 

MIN  LON  OF  STATESPACE 

XMAX 

REAL 

1 

5 

MAX  LON  OF  STATESPACE 

YMIN 

REAL 

1 

6 

MIN  LAT  OF  STATESPACE 

YMAX 

REAL 

1 

7 

MAX  LAT  OF  STATESPACE 

NALT 

INT 

1 

8 

NUMBER  OF  ALTITUDES 

NDIR 

1ST 

1 

9 

NUMBER  OF  DIRECTIONS 

IDUM 

INT 

1 

10 

OF  MASKING  POINTS 

IDVE 

CH04 

1 

11 

VEHICLE  NAME  FOR  STATES 

ARMX 

REAL 

1 

12 

LAMDA  -  AIR  DAMAGE 

FLAM 

REAL 

1 

13 

LAGRANGE  MULTIPLIER 

ALTS 

REAL 

5 

14 

ALTITUDE  GRID  (M) 

XSCL 

REAL 

1 

19 

MIN  LON  OF  SCENARIO 

XSCU 

REAL 

1 

20 

.MAX  LON  OF  SCENARIO 

7SCL 

REAL 

1 

21 

MIN  LAT  OF  SCENARIO 

TSCU 

REAL 

1 

22 

.MAX  LAT  OF  SCENARIO 

PCAP 

REAL 

5 

23 

PROB  OF  CLOBBER  GRID 

IDC 

INT 

1 

28 

RECORD  CREATION  DATE 

IDM 

INT 

1 

29 

RECORD  MODIFICATION  DATE 

K> 


K 


The  first  item  in  the  table  is  the  ID  which  is  always  equal  to  ALGP.  The 
next  two  items  define  the  statespace  cell  size.  DELE  is  the  longitude  increment 
and  DELN  is  the  latitude  increment.  Typically  these  two  numbers  are  equal. 
Currently  the  values  are  both  2.4  nautical  miles.  The  next  four  items  define 
the  statespace.  XMIN  and  YMIN  are  the  longitude  and  latitude  of  the  southwest 
corner  of  the  statespace.  XMAX  and  YMAX  define  the  northeast  corner.  As  is 
standard  for  all  the  tables,  the  values  are  in  decimal  degrees;  longitude  is 
positive  east  and  latitude  is  positive  north.  The  variables  XSCL,  XSCU,  YSCL, 
and  YSCU,  define  the  scenario.  XSCL,  and  YSCL  are  the  longitude  and  latitude  of 
the  southwest  (lower)  corner  of  the  scenario.  XSCU  and  YSCU  are  the  longitude 
and  latitude  of  the  northeast  (upper)  corner  of  the  scenario.  The  scenario  must 
contain  the  statespace.  NALT  is  the  number  of  altitude  levels  that  will  be  used 
in  constructing  the  three  dimensional  statespace  (TH3D).  NALT  may  be  as  low  as 
1  and  should  never  exceed  5.  It  is  currently  set  to  5.  NDIR  is  the  number  of 
directions  used  in  generating  the  statespace.  It  must  be  set  to  8  for  this 
version  of  FLAPS.  This  corresponds  to  a  45  degree  angular  separation  of 
adjacent  directions.  IDUM  is  the  number  of  masking  points  and  should  be  set 
equal  to  2.  IDVE  is  the  ID  of  the  vehicle  for  which  the  statespace  is  to  be 
built.  IDVE  must  match  an  ID  for  one  of  the  Vehicle  Parameters  table  (VEHP) 
records.  The  statespace  will  be  built  assuming  that  all  vehicles  are  flying  at 
the  nominal  velocity  (VNOM  in  VEHP)  for  the  vehicle  specified  by  IDVE.  ARMX  is 
the  air  danger  per  second.  It  is  applied  to  all  transition  costs  in  the 
statespace.  A  vehicle  flying  through  enemy  airspace  is  at  risk  even  if  it  is 
not  within  the  coverage  of  any  known  threats.  FLAPS  models  this  risk  with  ARMX. 
It  should  always  be  a  very  small  number.  FLAM  is  the  Lagrange  multiplier  which 
is  used  to  ensure  that  the  routes  generated  by  the  dynamic  programming  algorithm 
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are  direct  and  fuel  efficient.  It  is  also  in  the  units  of  danger  per  second. 
ALTS  is  the  list  of  above  ground  level  clearance  altitudes  that  are  used  in 


building  the  statespace.  The  altitudes  are  in  meters.  In  ouilding  TH3D,  threat 
exposure  is  calculated  for  each  of  these  altitudes,  for  every  threat.  The  first 
Malt  values  should  be  greater  than  0.  ?CAP  is  the  "constant  probability  of 
clobber  grid"  and  is  not  now  being  used. 


A. 1.3. 2  ALGP  Table  Usage  - 

The  ALGP  table  defines  both  the  scenario  space  and  the  statespace.  It  is 
critical  that  it  be  defined  properly  or  else  the  threat  modeling  calculations, 
vhich  are  very  time  consuming  relative  the  the  rest  of  FLAPS,  vill  be  incorrect. 
The  normal  user  should  never  have  to  change  the  values  of  ALGP.  However,  if 
that  becomes  necessary,  the  following  information  vill  be  useful. 

Please  note  that  the  statespace  must  be  completely  contained  within  the 
scenario  space.  The  statespace  must  also  be  completely  contained  within  the 
boundaries  of  the  byte  packed  terrain  data  (BYTE)  file.  Please  see  sections 
3.2.13,  3.2.10,  and  3.2.17  for  desciptions  of  TH3D,  STAT,  and  BYTE. 

The  statespace  contains  vhat  are  called  "transition  costs".  A  transition 

cost  is  defined  to  be  the  negative  log  of  the  probability  of  survival  going  from 

one  cell  to  another.  The  negative  log  probability  of  survival  is  often  referred 

to  as  "danger".  Because  each  cell  is  connected  to  eight  other  cells,  there  are 

0  . 

eight  transition  costs  per  statespace  cell.  Threat  lethalities  are  stored  in 
the  threat  model  table  (TMDL)  in1 the  form 'of  negative  log  probability  of 
survival  per  second.  To  calculate  a  transition  cost  from  a  TMDL  record  requires 


that  the  danger  per  second  be  multiplied  by  the  amount  of  time  it  takes  to  fly 
from  one  cell  to  another,  among  other  things.  At  this  time,  the  FLAPS 
statespace  is  built  for  only  one  vehicle.  This  is  in  spite  of  the  fact  that 
planning  is  being  performed  for  several  vehicles  types.  Currently  it  is  assumed 
that  the  differences  in  speed  and  threat  capability  between  the  F-4,  F-16,  and 
F-lll  are  small.  The  item  IDVE  is  the  ID  of  the  vehicle  for  which  the 
statespace  will  be  built. 

Routes  generated  using  the  dynamic  programming  algorithm  are  sensitive  to 
the  values  of  ARMX  and  FLAM.  The  current  values,  5.0  E-6  and  1.5  E-4 
respectively,  are  appropriate  for  the  forcel  level  planning  application.  SCT 
recommends  that  the  user  not  change  these  parameters. 
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A.1.4  THE  CURRENT  STATUS  (CURR)  TABLE 


The  Current  Status  Table  consists  of  a  single  record  of  data.  This 
record  describes  the  current  status  of  processing.  CURR  is  updated  by  the 
program  as  a  result  of  a  PROC  command,  or  an  ADD,  DELETE,  CHANGE  or  COPY  command 
to  any  other  table.  The  user  should  never  attempt  to  ADD,  DELETE  or  COPY  the 
CURR  table.  He  should  CHANGE  the  table  only  to  change  the  graphical  plotting 
device. 


The  structure  of  the  Current  Status  Table  is  shown  below.  This  excerpt 
may  be  recreated  by  typing  "SHOW  CURR  HELP". 


CUR R  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

ID 

CH04 

1 

i 

IADD 

INT 

1 

2 

IALT 

INT 

1 

3 

IAOP 

INT 

1 

4 

ICLO 

INT 

1 

5 

ISTO 

INT 

1 

6 

ILST 

CH04 

1 

7 

INDX 

INT 

1 

8 

IPRO 

INT 

1 

9 

ITYP 

INT 

1 

10 

IMSK 

INT 

1 

11 

IDEV 

CH04 

1 

12 

IDM1 

INT 

1 

13 

IDM2 

INT 

1 

14 

IDM3 

INT 

1 

15 

IDM4 

INT 

1 

16 

IDM4 

INT 

X 

17 

IDM5 

INT 

1 

13 

IDM6 

INT 

1 

19 

IDM7 

INT 

1 

20 

IDM8 

INT 

1 

21 

IDM9 

INT 

1 

22 

IDMO 

INT 

1 

23 

IDC 

INT 

1 

A. 

24 

IDM 

INT 

1 

25 

TITLE 
ID  =  CURR 

OF  THREATS  ADDED 
TERRAIN  ALT  INIDCATOR 
ALTITUDE  LEVEL 
CLOBBER  INDICATOR 
OP  STCH  THREATS  ADDED 
LAST  COMMAND  GIVEN 
INDEX  OF  LAST  ARC  DONE  A 
STATUS  OF  PROC  COMMAND 
TYPE  OF  LAST  ARC  DONE  A 
OF  THREATS  MASKED 
INDEX  OF  LAST  ARC  DONE  T 
DEVICE  CHARACTER 
DUMMY  NOT  YET  USED 
DUMMY  NOT  YET  USED 
DUMMY  NOT  YET  USED 
DUMMY  NOT  YET  USED 
DUMMY  NOT  YET  USED 
DUMMY  NOT  'YET  USED 
DUMMY  NOT  YET  USED 
DUMMY  NOT  YET  USED 
DUMMY  NOT  YET  USED 
DUMMY  NOT  'YET  USED 
RECORD  CREATION  DATE 
RECORD  MODIFICATION  DATE 
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The  first  item  is  the  record  ID  and  is  always  equal  to  CURR.  Of  the 
remaining  items,  only  IAOP,  IPRO  and  IDEV  are  currently  used  by  the  program. 


IAOP  is  the  altitude  level  used  in  the  altitude  optimization  algorithm  of 
statespace  construction.  The  user  specifies  this  level  in  response  to  a  prompt 
issued  by  the  STATES  AOPT  and  PROC  commands  as  described  in  section  2.  IDEV  is 
the  plotting  device  currently  in  use,  as  described  in  the  DISPLAY  command  of 
section  2.  IPRO  is  the  status  of  processing  as  defined  below. 


IPROCU  =  "STATUS  OF  PROCESSING" 

"=  0:  GEOMETRY  TO  BE  DONE" 

"=100:  GEOMETRY  OK;  STATESPACE  TO  BE  CLEARED" 
"*120:  STATESPACE  CLEARED;  MASKING  TO  BE  DONE" 
"=140:  MASKING  COMPLETE:  THREATS  TO  BE  ADDED" 
"=150:  THREATS  ADDED:  STCHS  TO  BE  ADDED" 

"=160:  STCHS  ADDED;  CLOBBER  TO  BE  DONE" 

"=180:  CLOBBER  OK;  AOPT  TO  BE  DONE" 

"=200:  STATESPACE  OK;  NODES  TO  BE  DONE 
"=250:  NODES  OK;  ACCESS  TO  BE  DONE" 

"=300:  ACCESS  OK;  ARCS  TO  BE  COMPLETED" 

"=400:  ARCS  OK;  ROUTES  TO  BE  DONE" 

"=500:  ROUTES  OK;  ALLOCATE  TO  BE  DONE" 

"=600:  ALLOCATE  OK" 


A. 1.4.1  CURR  Table  Usage  - 

The  CURR  table  is  changed  by  the  user  using  the  standard  table  CHANGE 

command.  Only  the  IDEV  item  should  be  selected  for  changing.  Possible  values 

for  this  item  depend  on  the  available  hardware  configuration.  Because  the  data 

type  of  this  item  is  character,  values  like  4014  and  4115  which  are  normally 

treated  as  integers  must  be  enclosed  in  double  quotation  marks  with  no  embedded 

blanks.  IDEV  may  take  one  of  the  following  values. 

CRT  24  'x  80  alphanumeric  display  (poor  resolution) 

HP  Hewlett  -  Packard  X  -  Y  Plotter 

PTX  Printronix  High  -  resolution  line  printer 


SEL 

"4014 


"4 


Selenar  3oard  (VT-100  with  special  hardware) 
Tektronix  4014  and  4014  emulators  (4014 

emulation  software  is  avaliable  for  the  Macintosh) 
115"  Tektronix  4115 


The  standard  display  device  is  the  Tektronix  4115B.  Users  on  other 
systems  must  make  sure  that  TDEV  is  set  appropriately.  The  FIND  and  LOCATE 
commands  are  only  supported  on  the  4115B. 


The  value  of  IPRO  is  set  automatically  by  the, program.  It  is  increased 
on  a,  PROCESS  command,  according  to  the  last  algorithm  successfully  completed. 
Thus,  for  example,  if  the  PROCESS  command  successfully  completed  all  the  way 
through  ALLOCATE,  IPRO  would  be  set  to  600;  while,  if  it  exited  after 
successfully  completing  ACCESS,  IPRO  would  be  set  to  300.  The  value  of  IPRO  may 
be  decreased  on  an  ADD,  DELETE,  CHANGE  or  COPY  command.  In  this  case,  IPRO  is 
set  to  the  smaller  of  its  previous  value  and  the  value  of  the  IAFT  item  in  the 
Table  Structure  Table  (.See  Section  3.1.1).  Values  for  IAFT  are  as  follows: 

CRSHOV  —  RECORD  2  IDVORD-ASTR 

IAFT-  0 

CRSHOV  —  RECORD  3  IDVORD-ALGP 

IAFT-  0 

CRSHOV  —  RECORD  4  IDV0RD-CMDL 

IAFT*  100 

CRSHOV  —  RECORD  5  IDVORD-CURR 

IAFT-  600 

CRSHOV  —  RECORD  6  IDVORD-DISP 

IAFT-  600 

CRSHOV  —  RECORD  7  IDVORD-GEOM 

IAFT-  0 


CRSHOV  —  RECORD 


3 


HE 


IDVORD-LLTR 


CRSHOW 

—  RECORD 

9 

IDWORD=NODP 

IAFT= 

250 

CRSHOW 

—  RECORD 

10 

IDW0RD=PB0R 

IAFT= 

600 

CRSHOW 

—  RECORD 

11 

IDWORD=ROZ 

I  AFT* 

600 

CRSHOW 

—  RECORD 

12 

IDWORD=SPED 

I  AFT* 

600 

CRSHOW 

—  RECORD 

13 

IDWORD=STCH 

IAFT* 

100 

CRSHOW 

—  RECORD 

14 

IDWORD=STGB 

IAFT= 

200 

CRSHOW 

—  RECORD 

15 

IDWORD=SUPM 

IAFT* 

100 

CRSHOW 

—  RECORD 

16 

IDWORD*SUPP 

IAFT= 

100 

CRSHOW 

—  RECORD 

17 

IDWORD*SWCH 

IAFT* 

100 

CRSHOW 

—  RECORD 

18 

IDWORD-TG 

IAFT* 

200 

CRSHOW 

—  RECORD 

19 

IDWORD-THRT 

IAFT* 

100 

CRSHOW 

—  RECORD 

20 

IDWORD-TMDL 

IAFT* 

100 

CRSHOW 

—  RECORD 

21 

IDWORD-VEHP 

I  AFT* 

0 

CRSHOW 

—  RECORD 

22 

IDWORD.WEAP 

I  AFT* 

400 

CRSHOW 

—  RECORD 

23 

IDWORD=WFZ 

I  AFT* 

600 

Thus  for  example,  if  the  value  of  IPRO  is  600,  and  the  user  changes  the 
LLTR  file,  then  IPRO  vould  be  reduced  to  200.  A  HELP  STATUS  command  (section 


2.1.1)  vould  show  that  the  STATESPACE  is  still  good,  but  the  NODES,  ACCESS, 
ARCS,  ROUTES,  and  ALLOCATE  arrays  are  bad. 


An  example  of  the  relevant  items  in  the  CURR  table  is  shovn  below. 
CRSHOW  —  RECORD  2  IDVORD=CURR 


ID  =. 

CURR 

IA0P= 

2 

IPR0= 

600 

IDEV= 

4115 

IDC  = 

505291337 

IDM  > 

505291353 
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A. 1.5  THE  DISPLAY  (DISP)  TABLE 


The  Display  Table  consists  of  three  records  of  data  vhich  contain 
parameters  necessary  for  writing  to  four  different  graphic  display  devices 
information  in  this  table  supports  Lambert  Conformal  Projection  plots.  Th 
information  in  this  table  is  internal  to  the  display  algorithms.  The  user 
should  never  directly  modify  this  table. 


The  structure  of  the  DISP  table  is  shown  below.  This  table  may  be 
recreated  by  typing  "SHOW  DISP  HELP”. 


DISPLAY  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

IDEV 

CH04 

1 

1 

PLOTTING  DEVICE 

LMIN 

INT 

1 

t 

MIN  HORIZONTAL  RASTER 

MMIN 

INT 

1 

3 

MIN  VERTICAL  RASTER 

LMAX 

INT 

1 

4 

MAX  HORIZONTAL  RASTER 

MMAX 

INT 

1 

5 

MAX  VERTICAL  RASTER 

XSCL 

REAL 

1 

6 

HORIZ  RASTER  ./  DEG  LONG. 

YSCL 

REAL 

1 

7 

VERT  RASTER  /  DEG  LAT. 

XSUB 

REAL 

1 

8 

LONG  AT  HORIZ  RASTER  *  0 

YSUB 

REAL 

1 

9 

LAT  AT  VERT  RASTER  *  0 

XMIN 

REAL 

1 

10 

MIN  LONG  IN  VINDOV  (DEG) 

YMIN 

REAL 

1 

11 

MIN  LAT  IN  VINDOV  (DEG) 

XMAX 

REAL 

1 

12 

MAX  LONG  IN  VINDOV  (DEG) 

YMAX 

REAL 

1 

13 

MAX  LAT  IN  VINDOV  (DEG) 

IMIN 

INT 

1 

14 

MINIMUM  I  IN  VINDOV 

JMIN 

INT 

1 

15 

MINIMUM  J  IN  VINDOV 

IMAX 

INT 

1 

16 

MAXIMUM  I  IN  VINDOV 

JMAX 

INT 

1 

17 

MAXIMUM  J  IN  VINDOV 

XLB1 

REAL 

1 

18 

1ST  LABELLED  LONG.  (DEG) 

DXLB 

REAL 

1 

19 

DELTA  LABELLED  LONG (DEG) 

NXLB 

INT 

1 

20 

NUMBER  OF  LABELLED  LONGS 

YLB1 

REAL 

1 

21 

1ST  LABELLED  LAT  (DEG) 

DYLB 

REAL 

1 

22 

DELTA  LABELLED  LAT  (DEG) 

NYLB 

INT 

1 

23 

NUMBER  OF  LABELLED  UTS. 

LAT1 

REAL 

1 

24 

1ST  ZERO  DISTORTION  UT 

LAT2 

REAL 

1 

25 

2ND  ZERO  DISTORTION  UT 

XCEN 

REAL 

1 

26 

CENTRAL  LONGITUDE 

RCON 

REAL 

1 

27 

DEG  FR  YMAX  TO  PROJ  POLE 

TSCL 

REAL 

1 

28 

ANGULAR  SCALE  (DEG/ LONG) 

LSCL 

REAL 

1 

29 

UMBERT  LON  SCALE  FACTOR 

MSCL 

REAL 

1 

30 

UMBERT  UT  eCALE  FACTOR 

A. 1.6  THE  GEOMETRY  (GEOM)  TABLE 


The  Geometry  Table  consists  of  a  single  record  of  data.  The  Geometry 
Table  is  created  by  the  program  during  the  GEOM  command.  This  is  normally 
performed  at  program  initialization  and  is  invisible  to  the  user.  The  user 
should  never  attempt  to  ADD,  DELETE,  CHANGE,  or  COPY  the  GEOM  table.  Most  of 
this  data  is  based  on  the  data  in  the  ALGP  table.  The  scenario  geometry  is 
modified  by  changing  ALGP. 

The  structure  of  the  Geometry  Table  is  shown  below.  This  table  may  be 
recreated  by  typing  "SHOW  GEOM  HELP". 


GEOM  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH04 

1 

1 

ID  =  GEOM 

NI 

INT 

1 

2 

NUMBER  OF  LONGITUDES 

NJ 

INT 

1 

3 

NUMBER  OF  LATITUDES 

NK 

INT 

1 

4 

NUMBER  OF  AGLS 

NL 

INT 

1 

5 

NUMBER  OF  DIRECTIONS 

XMAX 

REAL 

1 

6 

MAXIMUM  LONGITUDE 

XMIN 

REAL 

1 

7 

MINIMUM  LONGITUDE 

YMAX 

REAL 

1 

8 

MAXIMUM  LATITUDE 

YMIN 

REAL 

1 

9 

MINIMUM  LATITUDE 

AL 

REAL 

5 

10 

STATESPACE  ALTITUDES  (M) 

DX 

REAL 

3 

15 

STATESPACE  DELTS  (DEG,M) 

IDEL 

INT 

8 

18 

DELTA  I  (LTH  DIRECTION) 

JDEL 

INT 

8 

26 

DELTA  J  (LTH  DIRECTION) 

XO 

REAL 

3 

34 

STATESPACE  ORIGIN(DEG,M) 

IDC 

INT 

1 

37 

RECORD  CREATION  DATE 

IDM 

INT 

1 

38 

RECORD  MODIFICATION  DATE 

The  first  item  is  the  record  ID  and  is  always  equal  to  GEOM.  The  next 
three  items,  NI,  NJ,  and  NK  give  the  number  of  statespace  cells  in  the  east, 


north  and  vertical  direction.  The  number  of  cells  is  determined  by  the  size  of 


the  statespace,  the  cell  size,  and  the  number  of  altitude  levels  specified  in 


ALGP.  XMIN,  YMIN,  XMAX,  and  YMAX  are  the  southwest  and  northeast  corners  of  the 
statespace  respectively.  AL  contains  the  altitude  levels.  DX(1)  and  DX(2) 
contains  the  north  and  east  statespace  cell  size  in  decimal  degrees.  DX(3)  is 
not  currently  being  used.  IDEL  and  JDEL  define  the  eight  transition  directions 
and  are  used  by  the  dynamic  programming  algorithm.  XO  is  again  the  southwest 
corner  of  the  statespace. 
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A. 1.7  The  Low  Level  Transit  Route  (LLTR)  Table 


The  LLTR  table  defines  the  low  level  transit  route  (  LLTR.)  network 
connecting  the  staging  bases  with  the  FEBA.  This  table  must  be  constructed,  or 
modified,  by  the  user  to  model  the  transit  route  network  in  effect  at  the  time 
the  missions  are  to  be  flown.  It  contains  one  record  for  each  LLTR  node  point. 
This  record  defines  the  ID,  type  and  location  of  that  node  as  well  as  its 
interconnections  to  other  nodes.  Records  of  this  table  may  be  referred  to  by 
their  record  number  or  the  ID  of  the  node  as  in  the  commands  "SHOW  LLTR  4"  or 


:  N008" 

.  Illustrated 

below 

is  the  description  of  the  LLTR  table 

which 

is  generated  by 

the 

FLAPS  command  "SHOW  LLTR  HELP". 

NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH08 

1 

1 

ID  OF  TRANSIT  ROUTE  NODE 

X 

REAL 

2 

3 

LONG-LAT  OF  LLTR  NODE 

CLNG 

REAL 

1 

5 

TRANSIT  ROUTE  CEILING 

ITYP 

INT 

1 

6 

TRANSIT  ROUTE  TYPE 

ICON 

CH08 

3 

7 

LLTR  NODE  CONNECTIONS 

IDC 

INT 

1 

13 

RECORD  CREATION  DATE 

IDM 

INT 

1 

14 

RECORD  MODIFICATION  DATE 

!  first 

item  in 

each  record 

is  a  unique  ID  for  the  LLTR  node.  This 

may  be  up  to  8  alphanumeric  characters  long  and  the  first  character  must  be 
alpha.  The  second  item  consists  of  the  longitude  and  latitude  (in  that  order) 
of  the  node,  given  in  decimal  degrees  according  to  the  convention:  Longitude 
■►East /-West;  Latitude  +North/ -South.  Item  three  is  not  presently  used  by  the 
program.  Item  four  is  the  node  type:  type  0  -  inactive  node,  type  1  -  active 
entry  node,  type  2  -  active  intermediate  node,  type  3  -  active  exit  node.  Item 
five  is  a  list  of  the  other  LLTR  node  IDs  to  which  this  node  is  connected; 
presently  the  1ength  of  this  list  may  not  exceed  3.  A  connection  is  defined 
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only  for  Che  direction  from  the  staging  base  to  the  FEBA.  Therefore,  active 
exit  points  vill  have  no  connections  and  active  entry  points  must  have  at  least 
one  connecting  LLTR  node.  All  LLTR  nodes  must  be  inside  of  the  scenario  space, 
or  else  they  vill  be  ignored  by  the  program.  In  addition,  all  LLTR  exit  points 
must  be  inside  of  the  statespace.  This  is  because  the  dynamic  programming 
algorithm  (DPA)  is  used  to  generate  routes  from  the  LLTR  exit  points  to  the 
targets.  The  DPA  can  only  be  executed  between  cvo  points  if  they  are  both 
inside  of  the  statespace. 


I  ' 


I 


A. 1.8  The  Node  Parameter  (NOOP)  Table 


fryr, 

r.V, 

A.’.-, 


F. 
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The  node  parameter  table  NODP  contains  the  number  of  nodes  which  are 
active  in  the  specified  scenario.  NODP  is  an  exception  to  the  usual  FLAPS 
convention  that  tables  are  defined  by  the  user  and  arrays  defined  by  the  program 
-  NODP  consists  of  a  single  record  (  2  )  whose  items  are  computed  by  the  FLAPS 
command  "NODES".  The  contents  of  this  table  may  be  examined  with  the  command 
"SHOW  NODP  2"  but  NODP  records  should  never  be  added,  copied,  deleted  or  changed 


t. 


B 


by  the  user.  The  description  of  the  structure  of  NODP  illustrated  below  is 
produced  by  the  command  "SHOW  NODP  HELP". 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CR04 

1 

1 

ID  =  NODP 

NSB 

INT 

1 

2 

NUMBER  OF  STAGING  BASES 

NTR 

INT 

1 

3 

NUMBER  OF  LLTR  NODES 

NTG 

INT 

1 

4 

NUMBER  OF  TARGETS 

NTR1 

INT 

1 

5 

NBR  OF  LLTR  ENTRY  NODES 

NTR2 

INT 

1 

6 

OF  LLTR  INTERMED  NODES 

NTR3 

INT 

1 

7 

NBR  OF  LLTR  EXIT  NODES 

I  DC 

INT 

1 

8 

RECORD  CREATION  DATE 

IDM 

INT 

1 

9 

RECORD  MODIFICATION  DATE 

Item  one  of  the  record  is  the  table  ID  -  NODP.  Items  two,  three  and  four 


are  the  numbers  of  staging  bases,  LLTR  nodes  and  targets,  respectively, 


determined  to  be  active  and  within  the  geographical  region  of  interest.  For 
example,  inactive  LLTR  nodes  (ITYP*0),  targets  outside  the  statespace 


v.- 


boundaries,  and  staging  bases  and  LLTR  nodes  out  side  of  the  scenario  boundaries 
are  not  counted  and  are  excluded  from  consideration  in  the  mission  planning 
problem.  Items  five,  six  and  seven  allocate  the  total  in  item  three  among  the  3 
LLTR  node  types:  entry,  intermediate  and  exit. 


r 
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A. 1.9  The  Political  Border  (PSOR)  Table 


The  PSOR  table  contains  a  list  of  long/lat  points  that  outline  the 
political  borders  between  countries  in  a  scenario.  The  PBOR  table  is  used  to 
display  the  country  borders  on  the  TEKTRONIX  4115.  Each  record  can  contain  one 
or  more  borders  between  countries. 


A. 1.9.1  PBOR  Table  Structure  - 


The  structure  of  the  PBOR  table  is  shown  below.  This  table  may  b« 
reproduced  by  typing  "SHOV  PBOR  HELP". 

PBOR  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH08 

1 

1 

ID  OF  POLITICAL  30RDERS 

NPTS 

INT 

1 

3 

NBR  OF  PBOR  BOUNDARY  PTS 

XPB 

REAL 

200 

4 

LONG-LAT  OF  BNDRY  POINTS 

IDC 

INT 

1 

204 

RECORD  CREATION  DATE 

IDM 

INT 

1 

205 

RECORD  MODIFICATION  DATE 

The  first  item  in  the  PBOR  table  is  the  political  border  ID.  This  ID  may 
be  up  to  eight  characters  long  and  must  begin  with  an  alpha  character.  This  ID 
usally  describes  the  countries  around  the  borders  being  plotted.  The  second 
item  is  the  number  of  longitude/ latitude  points  in  each  record.  One  hundred 
points  is  the  maximum,  with  each  longi tude/lati tude  coordinates  counting  as  one 
point.  The  third  item  is  the  political  border  points  position  as  longitude  and 
latitude.  Longitude  and  latitude  are  in  decimaA  degrees.  The  data  points  must 
be  contiguous  (all  entered  in  either  clockwise,  or  counterclockwise  order). 
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A. 1.9. 2  PBOR  Table  Usage  - 


The  current  PBOR  files  contain  all  of  the  political  borders  for  Western 
Europe  vithin  the  current  scenario  space  (July  85  delivery).  The  user  will  not 
need  to  add  or  change  these  files.  If  the  scenario  is  increased  or  moved,  the 
PBOR  records  will  have  to  be  updated.  If  new  boundary  points  are  desired, 
records  may  can  be  added.  The  user  could  include  roads,  rivers  or  other 
cultural  boundaries  if  data  bases  are  available.  The  data  may  be  displayed  by 
using  the  BOUNDARY  and  MISSION  options  of  the  DISPLAY  command. 


An  example  of  a  PBOR  record  is  shown  below. 

CRSHOW  —  RECORD  5  IDtfORD-EASGER 

ID  =  EASGER 

NPTS=>  76 

XPB  *  1.2150E+01  5.0317E+01  1.2217E-01  5.0317E-01 
I.2333E+01  5.0167E+01  1.2333E+01  5.0233E+01 
1.2500E+01  5.0400E+01  1.2833E+01  5.0467E+01 
1.2950E+01  5.0400E+01  1.3000E+01  5.0433E+01 
1. 3050E+01  5.0517E+01  1.3167E-01  5.0517E-01 
1.3217E+01  5.0517E+01  1.3250E+01  5.0583E+01 
1.3300E+01  5.0567E+01  1.3417E+01  5.0633E+01 
1.3450E+01  5.0583E+01  1.3467E+01  5.0600E+01 
1 . 3500E+01  5.0633E+01  1.3517E+01  5.0717E+01 
1.3783E+01  5.0733E+01  1.3850E+01  5.0733E+01 
1.3883E+01  5.0750E+01  1.3900E+01  5.0800E+01 
1 . 4000E+01  5.0817E+01  1.4050E+01  5.0800E+01 
1.4083E+01  5. 0800E+01  1.4217E+01  5.0867E+01 
1 . 4217E+01  5.0900E+01  1.4383E+01  5.0900E+01 
1.4400E+01  5.0933E+01  1.4300E+01  5.0967E+01 
1.4333E+01  5.0967E+01  1.4283E+01  5.0983E+01 
1 . 4267E+01  5. 1000E+01  1.4300E+01  5.1050E+01 
1 . 4417E+01  5. 1017E+01  1.4500E+01  5.1050E+01 
1.4500E+01  5. 1017E+01  1.4583E+01  5.1000E+01 
1 . 4617E+01  5.0967E+01  1.4583E+01  5.0917E+01 
1.4650E+01  5.0933E+01  1.4617E+01  5.0867E+01 
1 . 4800E+01  5.0817E+01  1.4817E+01  5.0867E+01 
1.4967E+01  5. 1000E+01  1.5000E+01  5.1167E+01 
1.5033E+01  5.1283E+01  1.5000E+01  5.1317E+01 
1.4983E+01  5. 1400E+01  1.4967E+01  5.1467E+01 
1.4717E+01  5. 1517E+01  1.4700E+01  5.1550E-01 
1.4733E+01  5. 1617E+01  1.4717E+01  5.1667E+01 
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1.4667E+01 
1.4633E-01 
1.4700E+01 
1.4767E-01 
1.4633E-01 
1.470QE+01 
1 . 4533E+01 
1 . 4617E+01 
1 . 4633fc-01 
1 . 4133E-01 
1 . 4133E-01 
0 . OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
505231728 
505231728 


5.1733E-01 
5 . 1300E-01 
5 . 1917E-01 
5 . 2067E-01 
5 . 2133E-01 
5 . 2233E-01 
5.2383E-01 
5.2500E+01 
5.2583E-01 
5 . 2833E-01 
5.2967E-01 
0 . OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 


1.4667S-01 
1.4583E-01 
1.4717E-01 
1.4633E-01 
1.4700E-01 
1.46C0E-01 
1 . 4550E-01 
1 . 4600E-01 
1.4217E-01 
1.4167E-01 
1.4250E-01 
0. OOOOE-OO 
0 . OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 


5 . 1300E-01 
5 . 1333E-01 
5 . 2000E-01 
5 . 2100E-01 
5.2167E-01 
5 . 2267E-01 
5.2433E-01 
3 . 2533E-01 
5 . 2817E-01 
S.2867E-01 
5 . 3000E-01 
Q.OOOCE-QO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 
0. OOOOE-OO 


A. 1.10  ROZ: 


RESTRICTED  OPERATING  ZONE  TABLE 


The  restricted  operating  zone  table  is  used  to  store  the  locations  where 
the  planner  wishes  to  place  restricted  areas  of  flying.  Each  record  will 
contain  one  area  of  restricted  operating  zones. 


A. 1.10.1  ROZ  Table  Structure  - 


The  structure  of  the  ROZ  table  is  shown  below.  This  table  may  be 
reproduced  by  typing  "SHOW  ROZ  HELP". 

ROZ  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH08 

1 

1 

ID  OF  ROZ 

NPTS 

INT 

1 

3 

NBR  OF  ROZ  BOUNDARY  PTS 

X 

REAL 

20 

4 

LONG-LAT  OF  BNDRY  POINTS 

TON 

REAL 

1 

24 

TIME  ON  OF  ROZ 

TOFF 

REAL 

1 

25 

TIME  OFF  OF  ROZ 

IDC 

INT 

1 

26 

RECORD  CREATION  DATE 

IDM 

INT 

1 

27 

RECORD  MODIFICATION  DATE 

The  first  item  in  the  ROZ  table  is  the  restricted  operating  zone  ID. 

This  ID  may  be  up  to  eight  characters  long  and  must  begin  with  an  alpha 
character.  This  ID  can  refer  to  the  area  involved  or  anything  else  the  user 
wishes.  The  second  item  is  the  number  of  boundary  points  of  the  area.  There  is 
a  ainiaum  of  three  boundary  points  (triangle  shaped  area)  and  a  maximum  of  ten 
points  (ten-sided  polygonal  area).  The  third  item  contains  the  vertices  of  the 
restricted  operating  zone  as  longitude  and  latitude.  Longitude  and  latitude  are 
i n  iecimal  degrees.  The  vertices  must  be  contiguous  (all  entered  in  either 
.ocKvise,  or  counterclockwise  order).  The  fourth  item  is  the  time  of  day  the 
ROZ  is  on  and  the  fifth  item  is  the  time  of  day  the  ROZ  is  off.  At  this  time 
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'ON  and  TOFF  are  not  being  used.  TON  and  TOFF  vouid  be  in  decimal  hours. 


A. 1.10.2  ROZ  Table  Usage  - 


The  ROZ  table  is  added  by  the  user  vith  the  standard  table  ADD  command. 
Records  can  be  changed,  deleted,  or  copied.  The  data  may  be  displayed  by  using 
the  RZ  option  in  the  DISPLAY  command.  At  this  time,  RQZ's  are  only  used  for 
display  purposes  and  will  have  no  effect  on  the  routes.  It  is  assumed  that  the 
LLTR  data  is  correct  and  no  attempt  is  made  to  verify  that  ROZ's  are  in  fact 
avoided  by  the  current  set  of  available  LLTR's. 


An  example  of  a  ROZ  record  is  shown  below. 


CRSHOW  —  RECORD  2  IDVORD-AflLEN 


ID  - 
NPTS- 

X  « 


TON  . 
TOFF* 
IDC  » 
IDM  * 


AHLEN 

3 

7 . 6330E+00 
7 . 7670E+00 
0 . OOOOE+OO 
0. OOOOE+OO 
0. 0000E+00 
0. OOOOE+OO 
0. OOOOE+OO 
505231728 
505231728 


5 . 1667E+01 
5. 1917E+01 
0. OOOOE+OO 
0. OOOOE+OO 
0. OOOOE+OO 


8 . 1670E+00 
0. OOOOE+OO 
0. OOOOE+OO 
0. OOOOE+OO 
0. OOOOE+OO 


5 . 1583E+01 
0. OOOOE+OO 
0. OOOOE+OO 
0. OOOOE+OO 
0. OOOOE+OO 


A. 1.11  SPED 


The  SPED  table  contains  routes,  or  sorties,  stored  as  a  series  of 
waypoints  and  a  header.  Each  record  of  the  SPED  table  contains  one  route. 
Records  in  the  SPED  table  are  created  using  the  SELECT  command.  Refer  to  the 
description  of  the  SELECT  command  in  section  2.1.11  to  see  how  and  when  SPED 
records  may  be  created.  Each  SPED  record  is  quite  large  relative  to  the  other 
tables  in  FLAPS.  This  makes  SPED  records  rather  difficult  to  manipulate. 

Several  features  have  been  built-  into  FLAPS  to  make  using  the  SPED  table  as  easy 
as  possible. 

Routes  are  stored  in  the  SPED  table  to  support  three  commands.  First, 
the  DISPLAY  command  reads  SPED  records  in  order  to  graphically  display  routes. 
Refer  to  the  ROUT  option  in  the  DISPLAY  command  in  section  2.1.9.  Routes  are 
also  read  out  of  the  SPED  file  for  threat  exposure  analysis.  Refer  to  the 
ANALIZ  command  in  section  2.1.12.  Finally,  routes  stored  in  the  SPED  table  may 
be  printed  out  in  a  flight  plan  format.  Refer  to  the  PLAN  option  for  the  SHOW 
command  in  section  2.1.7  and  the  flight  plan  description  in  section  3.2.16. 

A. 1.11.1  Table  Structure  - 

The  structure  of  the  SPED  table  is  shown  below.  This  table  can  be 
recreated  by  typing  "SHOW  SPED  HELP". 

SPED  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH12 

1 

1 

SORTIE  ID  (USER  CHOOSEN) 

I  SB 

INT 

1 

4 

STAGING  BASE  INDEX 

ITG 

INT 

1 

5 

TARGET  INDEX 

PS 

REAL 

1 

6 

PROB  OF  SURVIVAL 

A-29 


PTH 

REAL 

1 

7 

?R0B  KILL  DUE  TO  THREATS 

DFLT 

REAL 

1 

3 

DISTANCE 

TTOT 

REAL 

* 

9 

TAKE  OFF  TIME 

TOT 

REAL 

l 

10 

TIME  ON  TARGET 

MPT 

INT 

1 

X 

11 

OF  COORDS  IN  PATH 

C00R 

REAL 

720 

T , X , 7 , A , HEADING , NODE 

IDC 

INT 

1 

732 

RECORD  CREATION  DATE 

IDM 

INT 

1 

733 

RECORD  MODIFICATION  DATE 

Each  SPED  record  is  exactly  733  vords  long.  The  record  represents  a 
total  route  from  the  staging  base  to  the  target  and  back  to  the  staging  base. 

At  this  time,  a  maximum  of  50  records  may  be  stored  in  the  SPED  table.  As  vith 
every  FLAPS  table,  the  first  record  contains  header  information,  so  that  a 
maximum  of  49  routes  may  be  stored. 

The  first  item  in  each  record  must  be  a  unique  ID.  The  ID  may  be  up  to 
12  characters  long,  the  first  character  should  be  an  alpha.  The  second  and 
third  items  in  each  SPED  record  are  the  indices  of  the  sortie  staging  base  (ISB) 
and  target  (ITG),  respectively.  These  index  numbers  correspond  to  the  NLIS 
array.  The  fourth  item  is  the  total  route  probability  of  survival  (PS).  The 
fifth  is  the  probability  of  kill  due  to  threats  (PTH).  The  total  probability  of 
survival  is  the  product  of  one  minus  the  probability  of  kill  due  to  threats  and 
one  minus  a  small  probability  of  kill  due  to  "air  danger".  The  sixth  item  is 
the  total  route  distance  (DFLT).  The  seventh  is  the  take  off  time  (TTOT)  in 
minutes.  The  eighth  is  the  time  on  target  (TOT)  in  minutes.  The  ninth  item  is 
the  number  of  vaypoints  in  the  route  (NPT). 


Next,  the  actual  coordinates  of  the  waypoints  are  stored  (COOR).  There 
are  six  components  of  a  waypoint.  The  first  is  the  time  in  minutes  at  vhich  the 
way  point  occurs,  the  second  and  third  are  the  longitude  and  latitude  both  in 
decimal  degrees,  the  fourth  is  the  altitude  (above  ground  level)  in  meters,  the 
fifth  is  heading  from  north  in  degrees,  and  the  sixth  is  an  integer  index.  The 
integer  index  corresponds  to  the  NLIS  array  and  will  be  nonzero  if  the  waypoint 
is  a  staging  base,  target  or  LLTR  node.  Each  SPED  record  may  contain  up  to  120 
waypoints.  Routes  with  fewer  waypoints  will  contain  zeros  after  the  last 
waypoint . 

A. 1.11.2  SPED  Table  Usage  - 

Records  in  the  SPED  table  may  be  shown,  added,  deleted,  changed  or  copied 
just  like  any  other  table.  However,  because  of  the  length  of  each  SPED  table 
record,  care  must  be  taken  when  working  with  the  SPED  table.  SPED  records 
should  only  be  added  using  the  SELECT  command.  The  user  should  feel  free  to 
delete  SPED  records  if  some  records  are  no  longer  needed  or  if  more  room  is 
needed.  The  user  should  never  have  to  change  items  in  a  specific  SPED  record  or 
copy  SPED  records.  The  user  may  wish  to  show  items  in  a  SPED  record  header, 
such  as  DFLT  or  PS.  If  this  is  the  case,  the  user  should  specify  the  items  he 
wishes  to  see.  Showing  an  entire  SPED  record  is  not  recommended  because  of  the 
length  of  the  COOR  item.  The  SHOV  PLAN  command  was  created  to  print  out  SPED 
records  in  an  easily  interpreted  form.  SHOW  PLAN  should  be  used  if  the  user 
wishes  to  see  the  actual  route  waypoints. 


Vhen  creating  a  SPED  record  using  SELECT,  FLAPS  will  automatically 


determine  an  ID  if  the  user  vishes.  The  ID  is  determined  as  follows:  The  first 
four  characters  of  the  SPED  ID  are  the  first  four  characters  of  the  name  of  the 
staging  base  a:  which  the  route  originated,  tne  fifth  c.naracter  is  an  underscore 
the  sixth  through  ninth  characters  are  the  first  four  characters  of  the 
name  of  the  target,  the  tenth  character  is  an  underscore,  and  the  eleventh  and 
twelfth  characters  are  a  sequence  number  between  01  and  09.  For  example,  the 
first  time  a  route  from  Ramstein  AFB  to  target  Casiav  is  put  in  the  SPED  table, 
the  ID  will  be  RAMS . CASL. 01 .  If  a  second  version  of  this  route  is  put  into  the 
SPED  table  (say  after  suppression  has  been  applied),  then  the  ID  will  be 
RAMS. CASL. 02.  Of  course  the  user  can  override  this  convention  by  inputing  his 
own  ID  while  executing  SELECT. 


Please  note  that  the  probability  of  survival  and  kill  data  is  valid  for 
the  route  at  the  time  it  was  created  only.  If  suppression  is  later  applied  or 
threats  are  added,  the  probability  of  survival  data  is  not  updated.  The  ANALIZE 
command  computes  probability  of  survival  on  the  current  statespace  and  should  be 
used  to  check,  the  impact  of  statespace  changes  on  specific  routes. 


An  example  of  a  SPED  record  is  shown  below. 


CRSHOV  —  RECORD  2  IDVORD-SMAR. SZPR 
ID  *  SMAR.SZPR 
ISB  »  1 

ITG  «  133 

PS  *  1.5513E-01 
PTH  =  3. 4473E-01 
DFLT*  1 . 7600E+03 
TTOT*  0. 0000E+00 
TOT  *  9 . 1139E+01 
NPT  *  52 

COORa  0.0000E-00-1 . 7500E+00  5.1583E+01  1.2000E+02 
4. 7937E+01  0.0000E+00  3 . 3942E-00-1 . 0000E+00 
5.2000E+01  1.2000E*02  1.0763E+02  O.OOOOE+OO 


2.4323E+01  4.0000E+00 
1 . 2569E+02  O.OOOOE+OO 
4. 9288E+01  1.2000E+02 
4.4401E+01  8 . 1150E+00 
1 . 1383E+02  O.OOOOE+OO 
4.9039E+01  1 . 2000E+02 
5.0109E+01  9.4423E+00 
8. 6115E+01  O.OOOOE+OO 
4.8978E+01  1 . 2000E+02 
5.5919E+01  1.0855E+01 
5.6508E+01  O.OOOOE+OO 
4. 9279E+01  1 . 2000E+02 
6. 1690E+01  1 . 2005E+01 
1.2203E+02  O.OOOOE+OO 
4.9200E+01  1 . 2000E+02 
6. 7871E+01  1 . 3302E+01 
9.0000E+01  O.OOOOE+OO 
4. 9040E+01  1 . 2000E+02 
6.9906E+01  1 . 3738E+01 
1.3444E+02  O.OOOOE+OO 
4. 9040E+01  1. 2000E+02 
7.0763E+01  1 . 3800E+01 
1.8705E+01  O.OOOOE+OO 
4. 9240E+01  1 . 2000E+02 
7. 1911E+01  1.3800E+01 
O.OOOOE+OO  O.OOOOE+OO 
4. 9960E+01  1.2000E+02 
7 . 7927E+01  1. 3489E+01 
3.4171E+02  O.OOOOE+OO 
5 . 0400E+01  1 . 2000E+02 
8.5754E+01  1.4672E+01 
6.2926E+01  O.OOOOE+OO 
5. 1040E+01  1 . 2000E+02 
8. 7553E+01  1.5045E+01 
O.OOOOE+OO  O.OOOOE+OO 
5. 1160E+01  1.2000E+02 
8.9199E+01  1.5294E+01 
3.9129E+01  O.OOOOE+OO 
5. 1567E+01  1. 2000E+02 
9 . 3900E+01  1.4920E+01 
3. 1601E+02  O.OOOOE+OO 
5.1640E+01  1.2000E+02 
9.4489E+01  1.4796E+01 
2. 2449E+02  O.OOOOE+OO 
5.0840E+01  1.2000E+02 
1.0322E+02  1 . 3551E+01 
2.1345E+02  O.OOOOE+OO 
5.0440E+01  1 . 2000E+02 
1.0447E+02  1 . 3365E+01 
1.6162E+02  O.OOOOE+OO 
5.0160E+01  1 . 2000E+02 
1.0782E+02  1 . 3800E+01 


5 . 1000E+01  1 . 2Q00E+02 
4. 2450E+01  7.6542E+00 
1.0547E+02  O.OOOOE+OO 
4. 9205E+01  1 . 2000E+02 
4 . 6960E+01  3.6872E-00 
1.0043E+02  O.OOOOE+OO 
4. 3948E+01  1 . 2000E+02 
5. 2933E+01  1 . 0129E+01 
8. 5533E+01  O.OOOOE+OO 
4. 9015E+01  1 . 2000E+02 
5 . 8911E+01  1 . 1466E+01 
5.2046E+01  O.OOOOE+OO 
4.9552E+01  1.2000E+02 
6.5828E+01  1 . 2867E+01 
1 . 1926E+02  O.OOOOE+OO 
4.9040E+01  1 . 2000E+02 
6.9656E+01  1 . 3738E+01 
O.OOOOE+OO  O.OOOOE+OO 
4.9080E+01  1 . 2000E+02 
7.0263E+01  1 . 3800E+01 
O.OOOOE+OO  O.OOOOE+OO 
4.9120E+01  1.2000E+02 
7 . 1555E+01  1 . 3863E+01 
3. 1458E+02  O.OOOOE+OO 
4. 9280E+01  1.2000E+02 
7.6160E+01  1 . 3800E+01 
3. 1510E+02  O.OOOOE+OO 
5.0160E+01  1 . 2000E+02 
7. 9507E+01  1 . 3365E+01 
5.5771E+01  O.OOOOE+OO 
5.0960E+01  1 . 2000E+02 
8.6854E+01  1.4920E+01 
4.4320E+01  O.OOOOE+OO 
5. 1120E+01  1 . 2000E+02 
8. 7803E+01  1.5045E+01 
4.4195E+01  O.OOOOE+OO 
5. 1320E+01  1 . 2000E+02 
9. 1189E+01  1 . 5617E+01 
2.7440E+02  3.0535E-39 
5. 1600E+01  1 . 2000E+02 
9.4248E+01  1.4858E+01 
2.7000E+02  0.0600E+00 
5. 1640E+01  1 . 2000E+02 
1.0147E+02  1 . 3551E+01 
1.8000E+02  O.OOOOE+OO 
5.0560E+01  1 . 2000E+02 
1.0412E+02  1.3427E+01 
2 . 2476E+02  O.OOOOE+OO 
5.0400E+01  1 . 2000E+02 
1.0605E+02  1 . 3489E+01 
1 . 3498E+02  O.OOOOE+OO 
4. 9960E+01  1.2000E+02 


1 . 30C0E-02 
4.9080E-01 
1 .  1363Et02 
2 . 7000E-02 
*.904QE-01 
1 . 1 750E-02 
3 . 0221E-02 
4.9552E-01 
1 . 2442E-02 
2 . 3665E-02 
4. 9015E-01 
1.304CE-02 
2.6612E-02 
4.8948E-01 
1 . 3637E-02 
2 . 9390E-02 
4. 9205E-01 
1.4088E-02 
3 . 0667E+02 
3 . 1000E+01 
1 . 7944E-02- 
2 . 2820E-02 
5 . 1583E-01 
0 . OOOOE-OO 
0 . OOOGE-OO 
0. OOOOE-OO 
0 . OOOOE-OO 


O.OOOOE-QO 
L . 2000E-02 
L.3728E-01 
C . C000E-00 
1 . 2000E-02 
1 . 2867E-C1 
0 .  C000E-00 
1.2000E-02 
1.1466E-01 
0 . OOOOE-OO 
1 . 2000E-02 
1 . 0129E-01 
O.OOOOE-QO 
1.2000E-02 
8 . 6372E-00 
0. OOOOE-OO 
1 . 20Q0E-02 
7 . 6542E-00 
0 . OOOOE-OO 
1 . 2000E-02 
■1. OOOOE-OO 
0. OOOOE-OO 
1 . 2000E-02 
0. OOOOE-OO 
O.OOOOE-QO 
0. OOOOE-OO 
0. OOOOE-OO 


.  1332E-02  1. 
,  2556E-02  0. 
.  9040E-01  1. 
.  1546E-02  1. 
.9934E-02  0. 
.  92Q0E-01  1. 
.  2164E-02  1. 
. 3220E-02  0. 
.  9279E-01  1. 
.  2741E-02  1. 
.  6554E-02  0. 
.3978E-01  1. 
.  3322E-02  9. 
.  3045E-02  0. 
.  9039E-01  1. 
.  2893E-02  3. 
. 8549E-02  0. 
.  9288E-01  1. 
. 5901E-02  4. 
.8800E-02  0. 
.  2000E-01  1. 
.  8333E+02-1 : 
.  2320E+02  0. 
. OQOOE-OO  0. 
. OOOOE-OO  0, 
.OOOOE-OO  0, 
.OOOOE-OO  0. 


.  38C0E-01 
.  OOCOE-OO 
,  200CE-02 
.  3302E-01 
•OOOOE-OO 
.  2C0CE-02 
.  2005E-Q1 
.OOOOE-OO 
.  2000E-02 
.  0852E-01 
.  OOOOE-OO 
.  20C0E-02 
.  4u23E-00 
.  OOOOE-OO 
.  2000E-02 
.  1150E-00 
.OCOOE-CO 
.  2000E-02 
.  OOOOE-OO 
.  OOOOE-OO 
.  2000E+02 
;  7500E-00 
.  OOOOE-OO 
.OOOOE-OO 
.  OOOOE-OO 
.OOOOE-OO 
.OOOOE-OO 


0 . OOOOE-OO  0. OOOOE-OO  0. OOOOE-OO  0. OOOOE-OO 
505091409 
505091409 


*'  '* 
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A. 1.12  STCH:  STOCHASTIC  THREAT  MODEL  TABLE 

The  stochastic  threat  model  is  used  for  those  threats  that  exhibit  one  or 
more  of  the  following  features.  The  exact  location  of  the  threat  is  not  known. 
The  threat  is  a  mobile  threat  whose  location  varies  with  time.  The  threat  is  a 
group  of  threats  that  are  spread  out  over  an  area  (such  as  tanks  along  a  road  or 
an  army  division).  This  table  contains  the  necessary  information  to  describe 
the  area  that  a  stochastic  threat  can  cover  without  terrain  masking.  The 
generic  threat  information  for  each  threat  is  obtained  from  the  threat  model 
table  (TMDL) . 


A. 1.12.1  STCH  Table  Structure  - 


The  structure  of  the  STCH  table  is  shown  below.  This  table  may  be 
recreated  by  typing  "SHOW  STCH  HELP". 


STCH  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH04 

1 

1 

THREAT  ID 

ITYP 

CH08 

1 

2 

THREAT  TYPE  NAME 

XSC 

REAL 

3 

4 

THREAT  LON , LAT ,  and  ALT 

EXNT 

REAL 

1 

7 

EXPECTED  OF  THREATS 

PEX 

REAL 

1 

8 

PROB  THREAT  EXISTS 

RUNC 

REAL 

1 

9 

RADIUS  OF  UNCERTAINTY 

NBPS 

INT 

1 

10 

OF  PTS  ON  STCH  BORDER 

XPBS 

REAL 

100 

11 

LON  LAT  OF  NTH  POINT 

FGRD 

REAL 

1 

111 

RATIO  OF  INT/GEO  GRID 

IDC 

)  INT 

1 

112 

RECORD  CREATION  DATE 

I  DM 

INT 

1 

113 

RECORD  MODIFICATION  DATE 

The  first  item  in  the  table  is  the  stochastic  threat  ID.  This  ID  is  four 
characters  long,  with  the  first  character  being  an  alpha.  The  second  item'is 
the  generic  threat  type  name.  This  name  can  be  up  to  eight  characters  long  with 
the  first  character  being  an  alpha.  The  threat  type  provides  a  pointer  into  the 
threat  model  table.  The  third  item  is  an  array  with  three  elements  that  gives 
the  threat  longitude,  latitude,  and  altitude.  This  item  is  used  when  the  threat 
is  contained  at  one  location  with  a  radius  of  uncertainty.  In  this  case,  the 
variables  containing  the  number  of  boundary  points  and  the  boundary  point 
locations  are  ignored  when  calculating  the  stochastic  area.  The  fourth  item 
gives  the  expected  number  of  threats  to  be  found  in  the  stochastic  area.  The 
fifth  item  gives  the  probability  of  existence  for  this  number  of  threats  in  the 
stochastic  area.  The  sixth  item  gives  the  radius  of  uncertainty  for  the 
location  of  this  threat.  The  seventh  item  gives  the  number  of  points  that 
describe  the  boundary  of  the  stochastic  area  for  this  threat.  A  stochastic  area 
can  be  described  by  up  to  50  points.  The  eighth  item  is  an  array  containing  the 
longitude  and  latitude  for  each  point  that  describes  the  boundary  of  the 
stochastic  area.  It  is  used  when  the  number  of  boundary  points  is  greater  than 
one.  Then  the  variables  containing  the  threat  location  and  radius  of 
uncertainty  are  ignored.  The  boundary  points  must  be  the  vertices  of  a  convex 
polygon.  They  must  also  be  entered  contiguously  (either  all  clockwise,  or  all 
counterclockwise).  The  ninth  item  is  the  ratio  of  the  integration  grid  size  to 
the  statespace  grid  size.  An  appropriate  value  to  use  for  this  variable  is  1.0. 


A. 1.12.2  STCH  Table  Usage  - 


m  v 


The  stochastic  threat  table  is  used  vhen  a  threat  is  a  mobile  threat,  an 
area  threat,  or  there  is  poor  information  as  to  it's  exact  location.  In  the 
cases  vhere  the  threat  is  a  mobile  or  area  threat,  a  convex  polygonal  model  is 
used  to  describe  the  threat  boundaries.  When  the  threat  is  a  point  with  a 
radius  of  uncertainty,  a  circular  model  is  used  to  describe  the  threat 
boundaries.  Terrain  masking  is  not  used  vhen  modeling  stochastic  threats. 

The  current  version  of  FLAPS  does  not  support  automatic  threat 
suppression  nor  threat  exposure  analysis  for  stochastic  threats.  In  other 
words,  if  the  user  has  stochastic  threats  in  his  statespace  and  he  applies 
suppression  using  the  SUPRESS  command,  then  the  stochastic  threat  will  not  be 
suppressed.  Similarly,  if  threat  exposure  is  calculated  for  a  route  using  the 
ANALYZ  command,  the  time  in  and  time  out  of  the  stochastic  threats  will  not  be 
reported.  However,  the  leg-by-leg  probability  of  survival  report  will  be 
correct . 


-  TV  .  .  ' 


A. 1.13  The  Staging  Base  (STGB)  Table 


The  staging  base  table  STGB  defines  the  Locations  and  resources  of  the 
staging  bases  from  vhich  missions  are  to  be  flovn.  It  contains  one  record  for 
each  staging  base  and  must  be  constructed  by  the  user  to  define  the  collection 
of  staging  bases  of  interest  to  his  mission  planning  problem.  These  records  may 
be  referred  to  by  their  record  number  or  by  the  staging  base  ID  as  in  the 
commands  "DELE  STG3  5"  or  "SHOW  STGB  RAMSTZIN" .  Illustrated  belov  is  a 
description  of  the  structure  of  the  STGB  table  produced  by  the  command  "SHOW 
STGB  HELP". 

THE  STAGING  BASE  (STGB)  TABLE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH08 

1 

1 

ID  OF  STAGING  BASE 

X 

REAL 

2 

3 

LONG-LAT  OF  STAGING 

BASE 

ITYP 

CH04 

1 

5 

TYPE  OF  AIRCRAFT  AT 

BASE 

NACR 

INT 

1 

6 

NUMBER  OF  AIRCRAFT 

NVEP 

INT 

10 

7 

NUMBER  OF  WEAPONS 

IDC 

INT 

1 

17 

RECORD  CREATION  DATE 

IDM 

INT 

1 

18 

RECORD  MODIFICATION 

DATE 

The  first  item  in  each  record  is  a  unique  alphanumeric  ID  for  the  staging 
base.  This  ID  may  be  up  to  3  characters  long  and  the  first  character  must  be 
alpha.  Item  tvo  is  the  location  of  the  staging  base  given  as  longitude, 
latitude  (in  that  order)  in  decimal  degrees  according  to  the  sign  convention: 
Longitude  -East/-Vest,  Latitude  *North/-South.  Item  three  defines  the  type  of 
aircraft  assumed  to  be  present  at  the  staging  base.  This  item  may  be  up  to  A 
alphanumeric  characters  long  and  must  agree  with  the  aircraft  ID  of  the  record 
in  the  vehicle  parameters  table  VEHP  vhich  describes  this  aircraft.  Item  four 


is  Che  number  of  aircraft  available  at  the  staging  base.  This  number  is  used  by 
the  allocation  algorithm  to  insure  that  the  proposed  allocation  of  aircraft  to 
targets  is  consistent  vith  the  aircraft  resources.  Item  five  is  a  list  of  the 
number  of  weapons  of  each  type  available  at  the  staging  base.  The  order  of  this 
list  must  be  consistent  vith  the  order  used  in  the  items  ISCL  (table  VEHP),  FCIN 
(table  VEHP) ,  PDVP  (table  VEAP)  and  NAME  (table  VEAP).  The  present  version  of 
the  FLAPS  allocation  algorithm  does  not  perform  a  detailed  accounting  of  numbers 
of  weapons  allocated  -  it  simply  checks  that  a  non-zero  number  of  the  selected 
weapon  type  is  available  at  the  selected  staging  base. 


A. 1.14  The  Suppressor  Model  (SUPM)  Table 


The  Suppressor  Model  Table  con:ains  data  about  the  generic  capabilities 
of  the  three  types  of  threat  suppressors  modeled  in  FLAPS.  Each  SUPM  record 
corresponds*  to  a  type  of  suppressor:  EF-111,  Gompass  Call,  or  Wild  Weasel.  For 
each  type  of  suppressor,  the  SUPM  table  describes  how  much  of  an  effect 
individual  suppressors  will  have  on  the  nearby  threats.  The  locations  of  the 
individual  suppressors  are  contained  in  the  suppressor  position  (3UPP)  table. 


A. 1.14.1  SUPM  Table  Stucture  - 


The  structure  of  the  SUPM  table  is  shown  below.  This  table  may  be 
recreated  by  typing  "SHOW  SUPM  HELP" . 


SUPM  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH08 

1 

1 

SUPP  MODEL  IDENTIFIER 

RAD 

REAL 

1 

3 

MAX  RADIUS  OF  THE  SUPPRE 

ICAP 

1ST 

1 

4 

SUPP  CAPACITY 

TYPE 

REAL 

25 

5 

LIST  THRT  TYPE  EFFECTIVE 

DEGR 

REAL 

25 

30 

DEGRADE  THRT  CAPACITY 

ID  C 

1ST 

1 

55 

DATE  SUPP  MODEL  CREATED 

IDM 

1ST 

1 

56 

DATE  SUPP  MODEL  MODIFIED 

The  first  item  in  the  table  is  the  suppressor  model  ID.  This  ID  may  be 


up  to  eight  characters  long.  The  first  character  should  be  an  alpha.  The 
second  item  is  the  suppressor  radius  (RAD)  in  nautical  miles.  This  is  the 
radius  over  vhich  the  suppressor  will  be  effective.  The  third  item  is  the 
suppressor  capacity  (ICAP).  This  is  the  number  of  threats  that  this  type  of 
suppressor  can  be  effective  against,  at  one  time.  The  fourth  item  is  a  list  of 
the. threat  types  (TYPE)  that  this  type  of  suppressor  is  effective  against.  Each 
threat  type  in  this  list  must  correspond  to  a  threat  model  ID  in  the  TMDL  table. 
A  maximum  of  25  threat  models  may  be  listed.  The  fifth  item  is  a  list 
containing  the  threat  model  degrade  factors  (DEGR).  This  list  must  correspond 
to  the  list  of  threat  types  in  TYPE.  Each  degrade  must  be  a  real  number  betveen 
0.0  and  1.0. 


A. 1.14. 2  SUPM  Table  Usage  - 


The  SUPM  table  is  much  like  the  threat  model  table  TMDL.  Each  one 
contains  generic  information  about  a  system.  A  threat  system,  a  SAM  for 
example,  in  the  case  of  TMDL;  and  an  EV  or  hard  kill  suppression  system  in  the 
case  of  SUPM.  Data  about  the  deployments  of  actual  threats  and  suppression 
aircraft  is  contained  in  the  threat  table  (THRT)  and  the  suppressor  position 
table  (SUPP)  respectively. 


The  user  should  be  avare  of  several  things  vhen  creating  records  in  the 
SUPM  table.  Currently,  the  above  ground  level  altitude  of  the  suppressor  is  not 
being  used  in  determing  the  suppressor  radius  of  coverage.  For  planning 
purposes,  the  model  vill  use  the  radius  RAD,  no  matter  how  high  or  low  each 
individual  suppressor  actually  flies. 

It  is  unrealistic  to  expect  a  single  Vild  Veasel  to  clear  out  a  large 
number  of  SAMS.  The  capacity  of  the  Vild  Veasel  is  ultimately  limited  by  the 
number  of  missiles  it  can  carry.  For  this  reason,  a  capacity  factor  has  been 
included  in  the  SUPM  table.  If  the  number  of  threats  within  the  radius  of 
coverage  of  a  suppressor  exceeds  its  capacity,  then  the  suppressor  effectiveness 
is  downgraded  by  a  factor  equal  to  the  the  capacity  of  the  suppressor  divided  by 
the  number  of  threats  within  its  coverage.  For  example,  if  ICAP-6  and  DEGR-0.5, 
then  as  long  as  the  number  of  threats  within  the  radius  of  coverage  is  six  or 
less,  then  each  threat  vill  be  degraded  by  a  factor  of  0.5.  However,  if  10 
threats  were  within  the  radius  then  each  of  them  would  be  degraded  by  the  factor 
6/10  *  0.5  =■  0.3.  Only  threat  types  matching  the  SUPM  TYPE  list  are  included  in 
the  calculation.  If  the  user  does  not  want  to  downgrade  suppressor 
effectiveness  in  this  way,  he  can  set  the  suppressor  capacity  to  a  large  number 
(like  1000000). 

Degrades  are  applied  to  the  threats  in  the  following  way.  If  a  threat 
site  (XTH  in  THRT)  falls  within  the  radius  of  coverage  of  a  suppressor,  and  if 
the  threat  type  is  in  the  SUPM  TYPE  list,  then  a  degrade  is  calculated. 
Nominally,  the  degrade  will  be  the  appropriate  number  in  DEGR.  The  degrade 
number  in  DEGR  corresponds  to  the  position  of  the  threat  type  in  the  TYPE  list. 
If  the  suppressor  capacity  is  not  exceeded,  this  will  be  the  aegrade 


contribution  from  this  suppressor.  If  other  suppressors  are  present,  their 
degrade  contributions  are  calculated  in  the  same  way.  Finally,  all  of  the 
contributions  are  factored  in  together  and  the  threat's  lethality  will  be 
degraded  in  the  statespace  (the  SUPPRESS  command).  Each  degrade  is  treated  like 
an  independent  "probability  of  shutting  the  threat  down."  The  effect  of  more 
than  one  suppressor  on  the  same  threat  is  multiplicative.  If  the  capacity  of 
one  of  the  suppressors  is  exceeded,  then  the  degrade  contribution  from  that 
suppressor  on  each  threat  is  downgraded  as  described  above.  FLAPS  will  warn  the 
user  of  this  during  the  SUPP  command. 

Finally,  it  is  important  that  the  degrades  in  DEGR  be  between  0.0  and 
1.0.  Negative  degrades  or  degrades  greater  than  1.0  (100£)  will  produce  errors 
in  the  statespace. 


A. 1.15  The  Suppressor  Position  (SUPP)  Table 


The  suppressor  position  table  is  used  to  store  the  locations  vhere  the 
planner  wishes  to  place  his  available  suppression  assets.  Each  record  in  the 
suppressor  position  table  will  contain  the  position  of  one  -suppression  asset. 


A. 1.15.1  SUPP  Table  Structure  - 


The  structure  of  the  SUPP  table  is  shown  below.  This  table  nay  be 
reproduced  by  typing  "SHOV  SUPP  HELP". 


SUPP  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

ID 

CH08 

1 

1 

TYPE 

CH08 

1 

3 

XSU 

REAL 

3 

5 

IDC 

INT 

1 

8 

IDM 

INT 

1 

9 

TITLE 

SUPPRESSOR  IDENTIFIER 
SUPPRESSOR  TYPE 
LONG, LAT. TERR  CLEAR  ALT 
DATE  SUPP  REC  CREATED 
DATE  MODIFICATION 


The  first  item  in  the  SUPP  table  is  the  suppressor  ID.  This  ID  nay  be  up 
to  eigh-t  characters  long  and  must  begin  with  an  alpha  character.  This  ID  need 
not  refer  to  the' type  of  suppressor  that  is  being  used.  The  second  item  is  the 
suppressor  type.  This  is  an  ID  up  to  eight  characters  long  and  must  natch  a 
suppressor  node!  ID  in  the  SUPM  table.  The  third  item  is  the  suppressor 
position  as  longitude,  latitude,  and  altitude  above  ground  level.  Longitude  and 
latitude  are  in  decimal  degrees;  altitude  is  in  meters. 


A. 1.15.2  Using  The  SUPP  Taole  - 


The  SUPP  table  may  be  added  to  or  changed  by  the  user  with  the  standard 
table  ADD  and  CHANGE  commands,  however  the  user  will  usually  prefer  to  create 
SUPP  records  graphically.  This  can  be  done  on  a  TEKTRONIX  4115B  graphics 
display  terminal  using  the  LOCATE  command.  These  records  must  be  deleted  in  the 
usual  way  if  the  data  is  no  longer  appropriate.  The  data  may  be  displayed  using 
the  SUPPRESSOR  option  of  the  DISPLAY  command.  A  suppressor  will  not  be 
effective  against  any  threats  if  it  has  been  placed  poorly.  Only  threats  whose 
centers  are  within  the  radius  of  coverage  of  a  suppressor  are  affected.  If  the 
user  does  not  see  any  effect  after  applying  suppression,  then  he  should  check 
the  suppressor  positions  and  the  suppressor  model.  If  the  degrades  are  very 
small  or  if  the  suppressor  capacity  is  exceeded,  then  little  effect  will  be 


seen. 


A. 1.16  The  Software  Switch  (SVCH)  Table 


The  SVCH  taole  contains  a  numoer  or  'software  switches"  which  control  the 
way  in  which  the  program  executes.  Most  of  these  switches  are  not  being  used  in 
the  current  version  of  FLAPS  and  are  only  included  to  provide  growth  potential 
for  the  future.  As  the  capabitiity  of  the  models  in  FLAPS  expand,  these 
svitches  will  become  useful.  That  is  why  the  switch  table  has  been  maintained. 
It  should  never  be  necessary  for  a  normal  user  to  modify  the  SVCH  table.  The 
table  will  be  write  protected  during  normal  execution.  The  normal  user  may  skip 
this  section. 

There  are  only  two  records  in  the  SVCH  table.  The  first  is  a  header 
record  and  the  second  is  a  record  containing  the  actual  data. 


A. 1.16.1  SVCH  Table  Structure  - 


The  structure  of  the  SVCH  table  is  described  below.  This  table  can  be 
recreated  by  typing  "SHOW  SVCH  HELP". 


SVCH  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH04 

1 

1 

ID 

IAOP 

INT 

1 

2 

ALTITUDE  OPTIMIZATION  ■ 

IARP 

INT  ' 

1 

3 

ARRAY  PROCESSOR: ION, OOFF 

I3YT 

INT 

1 

4 

BYTE  PACKED  TERRAIN 

ICL3 

INT 

1 

5 

CLOBBER 

ICVB 

INT 

1 

6 

CL  MODEL: 0-BERMAN, 1-GD 

IDCN 

INT 

1 

7 

DECONFLICTION 

■  w-" 
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IDUL 

INT 

1 

8 

DUAL  CONTROL :0=Y,1, 2 =N0 

IEND 

INT 

1 

9 

END  POINTS  OF  ARCS 

IFES 

INT 

1 

10 

INFEASIBLE  TRANSITIONS 

IGDS 

INT 

1 

11 

GD  RUN 

IGLD 

INT 

1 

12 

G  LOAD : 0=N0, U YES 

IMSK 

INT 

1 

13 

MASKING  (-  m  GD  APPROX) 

IPCS 

INT 

1 

14 

CONST  PROB  OF  CLOBBER 

IREQ 

INT 

1 

15 

REQUANTIZATION 

IRST 

INT 

1 

16 

RESTART  ARCS 

JRST 

INT 

1 

17 

RESTART  TARCS 

IRUF 

INT 

1 

18 

ROUGHNESS  FILE 

ISPD 

INT 

1 

19 

WRITE  SPED  FILE :YES  R  NO 

ISRD 

INT 

1 

20 

LOOK  AT  ALL  STATE  SPACE 

ITAV 

INT 

1 

21 

TARGET  AVOID 

ISHK 

INT 

1 

22 

SHRINK  ACCESS  BOX 

ICAV 

INT 

1 

23 

LABEL  DISPLAYS  (SECRET) 

IDM1 

INT 

1 

24 

DUMMY  NOT  USED  YET 

IDM2 

INT 

1 

25 

DUMMY  NOT  USED  YET 

IDM3 

INT 

1 

26 

DUMMY  NOT  USED  YET 

I  DC 

INT 

1 

27 

RECORD  CREATION  DATE 

IDM 

INT 

1 

28 

RECORD  MODIFICATION  DATE 

The  first  item  in  the  table  is  the  ID  which  is  always  set  to  "SWCH".  The 
IAOP,  ICLB,  ICVB,  IFES,  IGLD,  IPCS,  and  IRUF  switches  all  relate  to  three 
dimensional  route  planning  and  probability  of  clobber  modeling.  This  capability 
is  not  yet  available  in  FLAPS  and  these  switches  are  not  currently  used.  The 
IARP  switch  refers  to  a  special  hardware  configuration  which  is  currently  not 
available,  so  this  switch  is  not  being  used.  The  IBYT  svitch  refers  to  the 
level  of  terrain  data  subsampling  that  is  desired  when  reading  the  terrain  data 
from  the  byte  packed  terrain  data  file,  BYTE.  This  switch  must  be  set  to  1  in 
this  version  of  FLAPS  (no  subsampling).  The  IDCN  switch  is  for  automated 
deconfliction  of  routes  and  is  not  now  being  used.  The  IDUL  (dual  control) 
switch  will  have  a  small  effect  upon  the  route  generation  algorithm.  A  setting 
of  0  is  appropriate;'  a  setting  of  1  is  also  permissible.  The  IEND  switch 
controls  the  way  the  route  data  is  stored.  A  setting  of  1  is  appropriate  for 
this  version  of  FLAPS.  The  IGDS  svitch  refers  to  certain  constraints  on  routes 
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near  the  targe c  area  and  is  not  nov  being  used.  The  I.MSK  svch  refers  to  the 
level  of  detail  desired  in  the  terrain  masking  algorithm.  A  setting  of  2  is 
appropriate  for  this  version  of  FLAPS.  The  requantisation  and  restart  switches 

IREQ,  IRST,  and  JRST  are  not-being  used  at  this  time.  The  ISPD  switch  refers  to 

the  SPED  file  and  is  not  being  used.  The  ISRD  controls  the  way  the  statespace 
is  read  into  the  computer's  core  memory  from  disk.  A  setting  of  0  is 
appropriate  for  this  version  of  FLAPS.  The  target  avoidance  switch  ITAV  is  not 

now  being  used.  The  shrink  switch  ISHK  controls  the  vay  the  "accessible  nodes 

box"  (NBOX)  is  constucted.  A  setting  of  0  is  appropriate  for  this  version  of 
FLAPS.  The  ICAV  switch  controls  the  labeling  of  the  graphic  displays  and  is  not 
now  being  used.  IDM1,  IDM2,  and  IDM3  are  dummy  variables  which  are  not  now 
being  used. 

The  following  is  a  list  of  the  current  switch  settings.  This  is  what  the 
user  should  see  if  he  types  "SHOV  SVCH  2". 


CRSHOW  —  RECORD 


2 


IDVORD-SVCH 


A. 1.17  The  Target  (TG)  Table 

The  Target  Table  TG  defines  the  IDs.  locations,  types,  priorities, 
hardnesses,  and  desired  damage  levels  of  all  targets  of  interest  in  the  mission 
planning  problem.  This  table  must  be  constructed  by  the  user  and  consists  of 
one  record  for  each  target  up  to  a  maximum  of  u9.  These  records  may  be 
referenced  by  their  record  number  or  by  the  threat  ID  as  in  "SHOW  TG  12"  or 
"DELE  TG  MILOVTCE".  The  description  of  the  target  table  shown  below  is  produced 
by  the  command  "SHOW  TG  HELP". 

TARGET  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH08 

1 

1 

TARGET  ID 

XTG 

REAL 

2 

3 

LONG-LAT  OF  TARGET 

CLAS 

CH04 

L 

5 

CLASSIFICATION  OF  TARGET 

IPRI 

INT 

1 

6 

TARGET  PRIORITY 

ITYP 

INT 

1 

7 

TYPE  OF  TARGET 

?DMN 

REAL 

1 

3 

MIN  ?R0B  DAMAG  THRES  TAR 

IDC 

INT 

1 

9  ' 

RECORD  CREATION  DATE 

I  DM 

INT 

1 

10 

RECORD  MODIFICATION  DATE 

The  first  item  of  each  record  is  a  unique  alphanumeric  ID  for  that 
target.  It  may  be  up  to  8  characters  long  and  the  first  character  must  be 
alpha.  Item  tvo  is  the  target  location  given  as  longitude,  latitude  (in  that 
order)  in  decimal  degrees  according  to  the  sign  convention:  Longitude 
+East/-West ,  Latitude  +North/-South.  Item  three  is  a  4  character  target  class  • 
descriptor  not  presently  used  by  the  program.  Item  four  is  the  integer  valued 
priority  assigned  to  the  target.  This  item  controls  the  jrd.er  in  which  aircraft 
and  weapons  are  allocated  to  targets.  Thus  a  low  value  for  this  item  indicates 
a  high  priority  target.  Item  five  is  the  target  type  which  must  be  a  positive 
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integer  between  1  and  25.  This  item  is  used  as  an  index  to  determine  the 
targets  vulnerability  to  the  different  weapon  types.  Therefore  the  value  of 
this  item  must  be  consistent  with  the  order  of  the  values  in  the  item  PDVP  (in 
the  weapons  table  VEAP)  which  defines  weapons  effectiveness.  Item  six  is  the 
minimum  probability  of  damage  desirea  for  the  target  and  so  its  value  must  be  a 
real  number  between  0  and  1.  The  allocation  algorithm  examines  the  single  shot 
weapon  effectiveness  in  item  PDVP  (in  the  table  VEAP)  and  the  aircraft  veapon 
carrying  capacity  in  item  ISCL  (in  the  vehicle  parameters  table  VEHP)  to 
determine  how  many  aircraft  and  weapons  are  required  to  achieve  this  desired 
probability  of  damage.  Thus,  more  aircraft  (up  to  10)  will  be  allocated  to  this 
target  as  the  value  of  the  PDMN  item  approaches  1.0.  Conversely,  fewer  aircraft 
(down  to  2)  vill  be  allocated  as  its  value  approaches  0. 


A. 1.18  The  Threat  Location  (THRT)  Table 


The  Threat  Location  Table  contains  the  necessary  information  to  describe 
the  location  of  fixed  threats.  These  threats  vill  have  terrain  masking  applied 
to  them  before  being  included  in  the  statespace. 


A. 1.18.1  THRT  Table  Structure  - 


The  structure  of  the  THRT  table  is  shown  below.  This  table 


may  be  recreated  by  typing  "SHOV  THRT  HELP". 


THRT  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH04 

1 

1 

THREAT  ID 

ITYP 

CH08 

1 

2 

THREAT  TYPE 

XTH 

REAL 

3 

4 

GEOD  LON.LAT.ELE  OF  DEF 

PEX 

REAL 

1 

7 

PROBABILITY  THREAT  EXISTS 

I  DC 

INT 

1 

8 

RECORD  CREATION  DATE 

IDM 

INT 

1 

9 

RECORD  MODIFICATION  DATE 

The  first 

item  of 

this 

table 

is  a  threat  ID.  This  ID  can  be  up  to  four 

characters  long  with  the 

first 

character  being  an  alpha.  The  second  item  is  a 

threat  type  name. 

This  i 

name  can  be 

up  to  eight  characters  long  with  the  first 

character  being  an  alpha 

.  The 

threat  type  provides  a  pointer  into  the  threat 

model  table  (TMDL)  to  get  the  generic  information  about  this  threat.  The  third 
item  is  a  three  element  array  containing  the  threat  location  in  longitude, 


latitude,  and  altitude.  The  fourth  item  is  a  probability  of  existence  for  this 
threat,  record. 

A. 1.18.2  THRT  Table  Usage  - 

The  threat  location  table  is  used  by  the  modules  that  do  terrain  masking, 
adding  and  deleting  threats  from  the  statespace,  threat  suppression,  and  route 
analysis.  The  longitude  and  latitude  is  entered  as  decimal  degrees  with  east 
longitude  and  north  latitude  being  positive.  Altitude  is  entered  as  decimal 
meters.  The  probability  of  existence  is  entered  as  a  decimal  from  0.0  to  1.0  . 


A. 1.19  The  Threat  Model  (TMDL)  Table 


The  Threat  Exposure  Model  table  contains  the  generic  information  for  each 
type  of  threat  that  is  used  in  the  statespace.  The  model  contains  a  threat 
exposure  template  that  is  symmetric  around  the  dovnrange  axis.  This  model 
assumes  that  the  threat  template  is  a  vertical  cylinder,  and  contains  only  one 
set  of  danger  (negative  log  probability  of  survival)  values  for  all  altitudes. 


A. 1.19.1  TMDL  Table  Structure  - 


The  structure  of  the  TMDL  table  is  shovn  belov.  This  table  may  be 
recreated  by  typing  "SHOV  TMDL  HELP". 


TMDL  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH08 

1 

1 

SPECIFIC  THREAT  MODEL  ID 

RMAX 

REAL 

1 

3 

MAXIMUM  RANGE  OF  THREAT 

DMIN 

REAL 

1 

4 

MIN  LOG-PROB  INSIDE  RMAX 

NDRG 

INT 

1 

5 

NUMBER  OF  DOVNRANGE  PTS 

NCRG 

INT 

1 

6 

NUMBER  OF  CROSSRANGE  PTS 

DRG1 

REAL 

1  ' 

7 

1ST  DOVNRANGE  PT  (NM) 

CRG1 

REAL 

1 

3 

1ST  CROSSRANGE  PT  (NM) 

DDRG 

REAL 

1 

9 

DELTA  DOVNRANGE  (NM) 

DCRG 

REAL 

1 

10 

DELTA  CROSSRANGE  (NM) 

PLOG 

REAL 

200 

11 

PLOG  AT  NTH  CROSSRANGE 

DUM1 

REAL 

1 

211 

DUMMY  NOT  USED  YET 

DUM2 

REAL 

1 

212 

DUMMY  NOT  USED  YET 

DUM3 

REAL 

1 

213 

DUMMY  NOT  USED  YET 

DUM4 

REAL 

1 

214 

DUMMY  NOT  USED  YET 

DUM5 

REAL 

1 

215 

DUMMY  NOT  USED  YET 

HIGH 

REAL 

1 

216 

MAX  THREAT  HEIGHT 

FLOR 

REAL 

1 

217 

MIN  THREAT  DEPRES.  HT 

IDC 

INT 

1 

218 

RECORD  CREATION  DATE 

IDM 


INT 


1  219 


RECORD  MODIFICATION  DATE 


The  first  item  in  the  threat  model  table  is  a  generic  threat  ID.  This  ID 
contains  up  to  five  characters,  starting  with  an  alpha.  The  second 'item  is  the 
maximum  lethal  range  of  the  threat  in  decimal  nautical  miles.  The  third  item  is 
the  minimum  danger  (DMIN)  level  that  vill  be  applied  to  the  statespace  within 
the  threat's  maximum  radius.  The  user  may  set  DMIN  to  a  small  danger  level. 

This  will  tend  to  force  the  routes  to  fly  around  the  threat's  maximum  radius, 
rather  than  to  just  avoid  the  threat's  unmasked  coverage.  That  is,  even  if  a 
cell  is  terrain  masked  from  a  threat,  a  small  amount  of  danger  will  be  added  to 
the  statespace  at  that  cell.  DMIN  is  normally  set  to  0.0  in  scenarios  with 
dense  threat  coverage.  A  value  of  zero  is  appropriate  in  the  european  theatre. 
The  fourth  item  is  the  integer  number  of  downrange  points  up  to  a  maximum  of  20 
points.  If  the  number  of  downrange  points  is  set  to  one,  then  the  statespace 
algorithm  uses  the  first  value  in  the  log  probability  of  danger  array  to  create 
a  cookie  cutter  type  threat  template  at  all  unmasked  points.  The  fifth  item  is 
the  integer  number  of  crossrange  points  up  to  a  maximum  of  10  points.  The  sixth 
item  is  the  range  to  the  first  downrange  point  in  nautical  miles.  The  seventh 
item  is  the  range  to  the  first  crossrange  point  in  nautical  miles.  The  eight 
item  is  the  range  difference  between  downrange  points  in  nautical  miles.  The 
ninth  item  is  the  range  difference  between  crossrange  points  in  nautical  miles. 
The  tenth  item  is  an  array  that  contains  the  danger  template,  which  is  defined 
as  the  negative  log  of  probability  of  survival  per  second.  Each  set  of  twenty 
elements  in  this  array  contains  all  the  downrange  values  for  one  crossrange 
setting.  The  tenth  through  fourteenth  items  are  dummy  items  that  are  not  used 
at  this  time.  The  fifteenth  item  is  the  maximum  lethal  height  of  the  threat  in' 


meters . 


The  sixteenth  item  is  the  minimum  lethal  height  of  the  threat  in 
meters,  to  take  into  account  the  minimum  depression  angle  on  some  threats. 


A. 1.19. 2  TMDL  Table  Usage  - 


These  threat  templates  are  combined  vith  the  terrain  masked  templates  for 


each  threat  to  create  a  danger  statespace.  A  special  program  named  SKIPPK  has 
been  developed  by  SCT  to  format  SURVTAC  threat  template  data  into  a  form 
compatible  vith  the  FLAPS  TMDL  table. 


A. 1.20  The  Vehicle  Parameters  (VEHP)  Table 


The  Vehicle  Parameter  table  VEHP  defines  the  ID,  dynamics,  fuel 
characteristics,  veapon  carrying  capacity  and  radar  profile  for  all  the  aircraft 
of  interest  in  the  mission  planning  problem.  This  table  must  be  constructed  by 
the  user  and  consists  of  one  record  for  each  aircraft  type.  Records  may  be 
referenced  by  their  record  number  or  by  the  aircraft  ID  as  in  "DELE  VEHP  3"  or 
"SHOW  VEHP  F-16".  The  description  of  the  VEHP  table  shovn  below  is  produced  by 
the  command  "SHOW  VEHP  HELP". 


VEHICLE  PARAMETERS  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

ID 

CH04 

1 

1 

VNOM 

REAL 

1 

2 

CLM 

REAL 

1 

3 

DIV 

REAL 

1 

4 

FCAP 

REAL 

2 

5 

FCEG 

REAL 

2 

7 

FCIN 

REAL 

20 

9 

NMFC 

INT 

1 

29 

ISCL 

INT 

20 

30 

RCS 

REAL 

a 

50 

TRAD 

REAL 

i 

58 

TYP 

CH04 

l 

59 

I  DC 

INT 

l 

60 

IDM 

INT 

l 

61 

TITLE 

AIRCRAFT  ID 

AIRCRAFT  VELOCITY  (NM/S) 
MAX  CLIMB  RATE  (M/S) 

MAX  DIVE  RATE  (M/S) 

FUEL  CAPACITY  (POUNDS) 
FUEL  CONSUMP.  (EGRESS) 
FUEL  CONSUMP.  (INGRESS) 
NUMBER  OF  FUEL  CONFIGS. 
STD.  CONFIGURATION  LOAD 
RADAR  CROSS  SECTIONS 
MAX  TURN  RADIUS  (M) 
AIRCRAFT  TYPE 
RECORD  CREATION  DATE 
RECORD  MODIFICATION  DATE 


Item  one  of  each  record  is  a  unique  alphanumeric  ID  for  the  aircraft 
type.  It  may  be  up  to  4  characters  long  and  the  first  character  must  be  alpha. 
Item  two  is  the  nominal  aircraft  velocity  in  units  of  nautical  miles  per  second 
This  item  is  used  in  the  computation  of  flying  time  and  threat  exposure  along  a 
route.  Items  three  and  four  are  not  presently  used  by  the  program.  Item  five 


is  a  list  of  real  numbers  defining  the  aircraft  fuel  capacity  in  pounds  as  a 
function  of  the  fuel  configuration  selected.  Item  six  is  a  list  cf  raal  numbers 
defining  the  aircraft  fuel  consumption  rate  during  egress  in  pounds  per  second 
as  a  function  of  fuel  configuration  selected.  Item  seven  is  a  l_st  of  real 
numbers  defining  the  aircraft  fuel  consumption  rates  in  pounds  per  second  during 
ingress  as  a  function  of  fuel  configuration  selected  and  veapon  type  being 
carried.  This  array  is  dimensioned  (10,2).  Item  eight  is  the  allowable  number 
of  fuel  configurations  -  presently  set  at  2.  Item  nine  is  a  list  of  integers 
defining  the  weapon  carrying  capacity  of  the  aircraft  as  a  function  of  fuel 
configuration  selected  and  veapon  type  selected.  The  fuel  conf igurationorder  in 
items  five,  six,  seven  and  nine  must  be  consistent.  Likewise,  the  veapon  type 
order  in  items  seven  and  nine  must  be  consistent.  Items  ten  through  twelve  are 
not  presently  used  by  the  program! 


A. 1.21  The  Veapons  Effectiveness  (VEAP)  Table 

The  Veapons  Effectiveness  table  VEAP  defines  the  names  and 
characteristics  of  the  veapons  of  interest  in  the  mission  planning  problem. 

This  table  consists  of  a  single  record  (record  2)  which  must  be  created  by  the 
user.  The  contents  of  the  table  may  be  examined  vith  the  command  "SHOW  VEAP  2". 
The  description  of  the  VEAP  table  structure  shown  below  is  produced  by  the 
command  "SHOV  VEAP  HELP". 

VEAPONS  EFFECTIVENESS  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

IDVP 

CH04 

1 

1 

ID  >  VEAP 

PDVP 

REAL 

50 

2 

PK  VEAP  BY  TG  TYPE 

NMTY 

INT 

1 

52 

NUMBER  OF  VEAP  TYPES 

NAME 

CH08 

10 

53 

NAME  OF  VEAPON 

IDC 

INT 

1 

73 

RECORD  CREATION  DATE 

IDM 

INT 

1 

74 

RECORD  MODIFICATION  DATE 

The  first  item  is  the  table  ID,  which  is  always  "VEAP".  Item  two  serves 
as  a  simplified  version  of  the  "Bomber's  Encyclopedia".  It  consists  of  a  2 
dimensional  array  of  floating  point  numbers  between  0  and  1.  This  array  defines 
single  shot  probability  of  kill  as  a  function  of  weapon  type  and  target  type. 

The  array  is  currently  dimensioned  (10,25).  The  routing  and  allocation 
algorithms  use  these  probabilities  to  determine  the  number  of  veapons  and 
aircraft  required  to  obtain  the  level  of  damage  specified  for  each  target. 
Therefore  the  weapon  type  index  used  in  this  list  must  be  consistent  with  the 
corresponding  index  used  in  the  items  NVEP  (table  STGB),  FCIN  (table  VEHP)  and 
ISCL  (table  VEHP).  Similarly,  the  target  type  index  used  in  the  list  must  be 


consistent  vith  the  value  of  item  ITYP  (table  TG).  Item  three  is  the  number  of 
veapon  types  (up  to  10)  being  considered.  Item  four  is  a  list  of  up  to  10 
alphanumeric  veapon  type  names.  These  names  may  be  up  to  8  characters  long  and 
should  be  listed  in  the  order  consistent  vith  the  veapon  type  index  used  in  item 
PDUP  described  above. 
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A. 1.22  The  Weapons  Free  Zone  (WFZ)  Table 

The  weapon  free  zone  table  is  used  to  store  the  locations  where  the 
planner  wishes  to  place  weapons  free  air  space.  Each  record  will  contain  one 
weapons  free  zone. 

A. 1.22.1  WFZ  Table  Structure  - 

The  structure  of  the  WFZ  table  is  shown  below.  This  table  may  be 
reproduced  by  typing  "SHOW  WFZ  HELP". 

WFZ  TABLE  STRUCTURE 


NAME 

TYPE 

SIZE 

LOC 

TITLE 

ID 

CH08 

1 

1 

ID  OF  WEAPON  FREE  ZONE 

NPTS 

INT 

1 

3 

NUMBER  OF  BOUNDARY  POINT 

X 

REAL 

20 

4 

LONG-LAT  OF  WFZ  BNDRY  PT 

IDC 

INT 

1 

24 

RECORD  CREATION  DATE 

IDM 

INT 

1 

25 

RECORD  MODIFICATION  DATE 

The  first  item  in  the  WFZ  table  is  the  weapon  free  zone  ID.  This  ID  may 
be  up  to  eight  characters  long  and  must  begin  with  an  alpha  character.  This  ID 
can  refer  to  the  area  or  anything  the  user  wishes.  The  second  item  is  the 
number  of  boundary  points  of  the  area.  There  is  a  minimum  of  three  boundary 
points  which  would  be  plotted  as  a  triangle  and  a  maximum  of  ten  which  would  be 
plotted  as  a  polygon  with  terf  sides.  The  third  item  is  the  weapon  free  zone 
position  as  longitude  and  latitude.  Longitude  and  latitude  are  in  decimal 
degrees.  These  points  must  be  entered  in  contiguous  order  (either  clockwise,  or 
counterclockwise) . 
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A. 1.22. 2  WFZ  Table  Usage  - 


The  WFZ  table  is  added  by  the  user  vich  the  standard  table  ADD  command. 
Records  can  be  changed,  deleted,  or  copied.  The  data  may  be  displayed  by  using 
the  VF  option  in  the  DISPLAY  command.  At  this  time,  WFZ's  are  only  used  for 
display  purposes  and  will  have  no  effect  on  the  routes.  It  :s  assumed  that  the 
LLTR  data  is  correct  and  no  attempt  is  made  to  verify  that  WFZ's  are  in  fact 
avoided  by  the  current  set  of  available  LLTR's. 


An  example  of  a  WFZ  record  is  shown  below. 

CRSHOV  —  RECORD  2  IDWORD=DUSLDORF 
ID  »  DUSLDORF 
NPTSa  4 

X  =  6. 2500E+00  5 . 1450E+01  7.0000E-00  5.1083E-01 
7 . 6667EfOO  5.1500E+01  7.2500E-00  5.1767E*01 
0. OOOOEfOO  O.OOOOE+OO  O.OOOOE-OO  O.OOOOE+OO 
O.OOOOE-OO  0. OOOOEFOO  0. OOOOEFOO  O.OOOOE^OO 
0. OOOOEFOO  0 . OOOOEFOO  O.OOOOE-OO  0 . OOOOEFOO 
I DC  *  505231728 

IDM  =  505231728 


A. 2  ARRAYS 


This  section  describes  the  arrays  used  by  FLAPS  plus  two  special  data 
structures;  the  flight  plan  output  and  the  digital  terrain  elevation  data. 
Arrays  are  matrix  oriented  data  structures  which  are  created  and  maintained  by 
the  FLAPS  software.  Each  four  character  array  name  is  associated  with  a  random 
access  disk  file  (see  the  OPEN  command  in  section  2).  These  disk  files  each 
consist  of  2  or  more  2400  word  records.  The  first  record  of  each  array  is  a 
header  record.  This  record  contains  information  used  by  the  file  management 
software;  data  which  is  stored  in  an  array  begins  in  record  2. 

The  actual  record-oriented  format  of  an  array  is  uninteresting  to  the 
user;  it  only  needs  to  be  understood  by  the  program  developer.  The  names  and 
descriptions  of  the  FLAPS  data  base  arrays  are  listed  below. 

NAMES  AND  DESCRIPTIONS  OF  ARRAYS 

ARCS  ARC  VAYPOINT  ARRAY 

ARPE  TARG  INGRESS/EGRESS  PERF 

ITGC  TARG  ACCESSIBLE  TO  STGB 

ITRC  TREX  ACCESSIBLE  TO  TREN 


NBOX 


LIST  OF  TG  BOX  CORNERS 


ml:  s 


ST  OF  MODES 


MFCS 

ROUT 

SXPE 

TGUS 

TRPE 


MODE  POSITIONS 

ROUT  MODES  DIST  AND  PERF 

STG3  TO  LLTR  EXIT ' PERF 

TARGET  STATUS  ARRAY 

LLTR  TREE  PERFORMANCE 
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A. 2.1  THE  ARCS  COORDINATE  (ARCS)  ARRAY 


The  Arcs  Coordinate  Array  contains  the  coordinates  of  the  optimal  path 
segments  betveen  the  targets  and  their  accessible  LLTR  exit  points.  Each  target 
and  LLTR  exit  point  pair  will  have  an  associated  ingress  and  egress  arc.  The 
arc  performance  data  for  the  arcs  is  stored  in  the  Arc  Performance  Array  (ARPE). 

The  arcs  are  stored  and  displayed  in  the  form  of  waypoints.  Each  arc  is 
made  up  of  at  least  tvo  waypoints.  Each  waypoint  has  the  following  form:  time 
(in  hours),  longitude  (in  decimal  degrees),  latitude  (in  decimal  degrees),  above 
ground  level  altitude  (in  meters),  and  a  node  index.  Time  is  the  elasped  time 
from  the  beginning  of  the  arc.  The  first  waypoint  will  always  have  time  equal 
to  0.0.  The  node  index  refers  to  the  node  ID  stored  in  the  NLIS  array.  Only 
the  first  and  last  waypoints  will  have  nonzero  indices. 

The  Arcs  Coordinate  Array  is  created  by  the  ARCS  command.  The  user  may 
show  the  ARCS  array  after  this  command  has  been  executed.  To  show  an  arc,  the 
user  should  enter  "SHOW  ARCS".  FLAPS  will  then  prompt  the  user  for  a  target  ID 
or  index.  Either  may  be  entered,  whichever  is  more  convenient.  Then,  FLAPS 
will  prompt  the  user  for  an  LLTR  exit  point  ID  or  index.  Again  the  user  may 
enter  either  form  The  user  may  show  the  NLIS  array  to  determine  the 
correspondence  betveen  the  node  ID's  and  indices.  If  the  target  and  LLTR  exit 
point  )<-.ir  are  not  accessible,  then  FLAPS  will  give  the  user  an  error  message. 
Accessible  target  and  LLTR  exit  point  pairs  may  be  seen  by  showing  the  ITGC  or 
ARPE  arrays.  The  result  of  the  SHOW  ARCS  command  will  be  a  listing  of  the 
ingress  and  egress  arcs,  in  that  order,  as  a  sequence  of  waypoints.  The  form  of 
the  vaypoints  is  described  above. 


The  following  table  is  the  result  of  a  "SHOW  ARCS"  command.  The  table 


could  have  been  generated  by  entering: 


SHOW  ARCS  CASLAV  N150 
or 

SHOW  ARCS  134  N150,  or  SHOW  ARCS  CASLAV  79 


or 

SHOW  ARCS  134  79 

VRARCS  -  ARRAY  ARCS  -  12  POINT  INGRESS  ARC  FROM  CASLAV  (  134)  TO  N150  (  79) 


TIME 

LONGITUDE 

LATITUDE 

ALTITUDE 

NODE 

0.000 

11.100 

'51.500 

120.000 

N150 

0.133 

11.436 

50.240 

120.000 

0.146 

11.498 

50.120 

120.000 

0.158 

11.622 

50.040 

120.000 

0.239 

12.618 

49 . 600 

120.000 

0.248 

12.742 

49.600 

120.000 

0.253 

12.805 

49.640 

120.000 

0.266 

12.991 

49.640 

120.000 

0.278 

13.116 

49.720 

120.000 

0.433 

15.418 

49.680 

120.000. 

0.458 

15.418 

49.920 

120.000 

0.462 

15.383 

49.950 

120.000 

CASLAV 

VRARCS  -  ARRAY  ARCS  -  13  POINT  EGRESS  ARC  FROM  CASLAV  (134)  TO  N150  (  79) 


TIME 

LONGITUDE 

LATITUDE 

ALTITUDE 

NODE 

0.000 

15.383 

49.950 

120.000 

CASLAV 

0.024 

15.107 

49.800 

120.000 

0.034 

15.045 

49.720 

120.000 

0.080 

14.360 

49.720 

120.000 

0.139 

13.738 

49.320 

120.000 

0.152 

13.551 

49.320 

120.000 

0;  158 

13 . 489 

49.280 

120.000 

0.162 

13.489  ■ 

49.240 

120.000 

0.168 

13.427 

49.200 

120.000 

0.206 

12.867 

49.200 

120.000 

0.339 

11.498 

50.120 

120.000 

0.352 

11.436 

50.240 

120.000 

0.485 

11.100 

51.500 

120.000 

N150 
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A. 2. 2  THE  ARC  PERFORMANCE  (ARPE)  ARRAY 

The  Arc  Performance  Array  contains  the  distance  and  probability  of 
survival  for  each  arc  generated  by  the  "ARCS"  command.  For  each  target  and  each 
accessible  LLTR  exit  point  there  is  an  ingress  and  egress  arc.  The  accessible 
LLTR  exit  points  for  a  given  target  can  be  seen  by  shoving  the  ITGC  array.  The 
ARPE  array  contains  the  probability  of  survival  and  distance  for  each  of  these 
ingress  and  egress  arcs. 

The  Arc  Performance  Array  is  closely  related  to  the  Arc  Coordinate  Array 
(ARCS).  The  data  is  stored  seperately  because  only  the  performance  data  is 
needed  to  do  the  route  construction  (ROUT)  and  target  allocation  (ALLOCATE). 

The  Arc  Performance  Array  is  generated  by  the  ARCS  command.  The  user  may 
show  the  this  array  after  the  ARCS  command  has  been  run.  To  shov  this  array  the 
user  types  "SHOW  ARPE".  FLAPS  vill  then  prompt  the  user  to  enter  a  target 
index,  a  target  ID,  "ALL",  or  If  the  user  wishes  to  see  the  performance  of 

the  arcs  for  a  specific  target,  then  he  may  enter  the  target  index  or  target  ID, 
whichever  is  more  convenient.  If  all  of  the  arc  performances  are  required  the 
user  may  enter  "ALL".  A  "/"  will  cause  the  SHOW  command  to  abort,  and  control 
will  return  to  the  main  program.  The  output  vill  be  in  the  following  form:  "ID 
"  refers  to  the  target  ID  name,  "INDEX"  refers  to  the  NLIS  indices.  The 
ingress  and  egress  route  distances  and  probabilities  of  survival  are  then  shown. 
The  following  table  was  generated  by  FLAPS.  It  shows  the  arc  performances  for 
target  "CASLAV".  The  user  could  have  entered  either: 


SHOW  ARPE  CASLAV 


or 


SHOV  ARPS  134 


to  generate  this  table. 


VRPERF  —  ARRAY  ARPS  —  ARC  PERFORMANCES  FROM  CASLAV  (  134) 


INGRESS 


EGRESS 


ID 

INDEX 

DIST  (NM) 

PS 

DIST  (NM) 

PS 

V’. 

1 

N150 

79 

266.09 

0.2050 

279.40 

0.2367 

2 

N151 

80 

251.35 

0.2051 

264.66 

0.2369 

—  o*.  ' 

3 

N152 

31 

236.30 

0.2051 

250.11 

0.2370 

4 

N153 

32 

222.60 

0.2052 

235.91 

0.2371 

v’O 

5 

N154 

83 

209.27 

0.2053 

222.58 

0.2372 

6 

S088 

69 

178.38 

0.2055 

191.97 

0.2374 

L,._ 

7 

S089 

70 

170.71 

0.2056 

179.71 

0.2375 

**  ,• 

3 

S092 

71 

156.91 

0.2057 

167.73 

0.2376 

*. 

9 

S102 

72 

152.33 

0.2061 

158.22 

0.2376 

10 

S120 

73 

144.71 

0.2057 

131.37 

0.2378 

i  *  *. 1 " 

11 

S155 

84 

198.77 

0.2054 

211.59 

0.2372 

**  i.*' 


A. 2. 3  THE  TARGET  ACCESSIBILITY  .(ITGC)  ARRAY 


The  Target  Accessibility  Array  is  a  list  of  all  of  the  paths  that  one  can 
take  to  a  given  target  provided  he  returns  to  his  staging  base  on  the  shortest 
distance  path.  This  array  is  used  to  determine  which  LLTR  exit  points  should 
have  arcs  built  from  them  to  the  target  when  the  "ARCS"  command  is  given. 
Building  arcs  is  a  time  consuming  process.  By  carefully  applying  accessibility 
rules,  the  number  of  arcs  vhich  need  to  be  built  can  be  kept  to  a  minimum.  For 
example,  there  is  no  need  to  build  arcs  to  a  target  from  a  staging  base  (via  a 
LLTR  exit)  if  that  staging  base  does  nor.  have  weapons  which  will  be  effective 
against  that  target. 

There  is  one  ITGC  record  for  every  target  vhich  has  at  least  one  staging 
base  accessible  to  it.  Each  line  in  the  record  corresponds  to  a  potential  path 
from  a  staging  base  to  the  target.  The  path  is  uniquely  specified  by  giving  the 
staging  base,  LLTR  entry  point  and  the  LLTR  exit  point  which  would  be  used  to 
reach  the  target.  With  this  information,  the  actual  LLTR  node  sequence  can  be 
retrieved  from  array  ITRC. 

The  Target  Accessibility  Array  has  a  one-to-one  correspondence  with  the 
Staging  Base  to  LLTR  Exit  Performance  (SXPE)  Array.  That  is,  one  would  use  the 
ITGC  array  to  find  the  Staging  Base  to  LLTR  entry  to  LLTR  exit  paths  that  are 
feasible  for  a  given  target  and  then  use  the  SXPE  array  to  find  the  distance  and 
probability  of  survival  along  the  path  from  the  Staging  Base  to  the  LLTR  exit. 


The  Target  Accessibility  Array  is  generated  by  issuing  the  command 
"ACCESS”.  Changes  to  the  STG3,  LLTR,  TG,  VEAP  and  VEHP  tables  may  make  the  ITGC 
array  lave  stale  data.  The  following  ITGC  record  could  have  been  generated  by 
FLAPS  3y  issuing  the  command  "SHOV  ITGC  LEGNICA"  or  the  command  "SHOV  ITGC  135". 
If  all  ITGC  records  are  desired,  the  command  would  be  "SHOV  ITGC  ALL". 

VRACC  —  THERE  ARE  16  PATHS  TO  TARGZT  LEGNICA  (  135)  IN  ARRAY  ITGC 

STAGING  BASE  LLTR  ENTRY  LLTR  EXIT 


1 

MILDENHA  ( 

3) 

N156 

( 

17) 

S088 

( 

69) 

L 

MILDENHA  ( 

3) 

N156 

( 

17) 

S089 

( 

70) 

3 

MILOENHA  ( 

3) 

N156 

( 

17) 

S0.92 

( 

71) 

4 

MILDENHA  ( 

3) 

N156 

( 

17) 

S102 

( 

72) 

5 

MILDENHA  ( 

3) 

N156 

( 

17) 

S120 

( 

73) 

6 

MILDENHA  ( 

3) 

N156 

( 

17) 

S133 

( 

74) 

7 

MILDENHA  ( 

3) 

N156 

( 

17) 

S134 

( 

75) 

8 

MILDENHA  ( 

3) 

N156 

( 

17) 

S135 

( 

76) 

9 

MILDENHA  ( 

3) 

N156 

( 

17) 

3136 

( 

77) 

10 

MILDENHA  ( 

3) 

N156 

( 

17) 

S137 

( 

78) 

11 

MILDENHA  ( 

3) 

N156 

( 

17) 

N150 

( 

79) 

12 

MILDENHA  ( 

3) 

N156 

( 

17) 

N151 

( 

80) 

13 

MILDENHA  ( 

3) 

N156 

( 

17) 

N152 

( 

31) 

14 

MILDENHA  ( 

3) 

N156 

( 

17) 

N153 

( 

*2) 

15 

MILDENHA  ( 

3) 

N156 

( 

17) 

N154 

( 

83) 

16 

MILDENHA  ( 

3) 

N156 

( 

17) 

S155 

( 

84) 

A.  2. 4  THE  LOW  LEVEL  TRANSIT  ROUTE  ACCESS  (ITF.C)  ARRAY 

The  Lov  Level  Transit  Route  Access  Array  contains  the  optimal  LLTR  node 
sequences  from  a  given  LLTR  entry  point  to  every  LLTR  exit  point  which  can  be 
reached  from  that  entry  point.  It  also  shows  the  distance  through  the  network 
in  nautical  miles  and  the  probability  of  arriving  at  the  LLTR  exit  given  one 
left  from  the  LLTR  entry.  Even  though  the  route  from  the  LLTR  entry  point  to 
the  LLTR  exit  point  is  not  contained  in  the  statespace,  and  therefore  is  not 
exposed  to  any  threat  danger,  the  probability  of  survival  will  be  slightly  less 
than  1.0.  This  is  due  to  the  small  "air  danger"  penalty.  The  same  is  also  true 
for  the  TRPE  and  SXPE  arrays.  The  distance  and  probability  of  arrival  does  not 
change  on  ingress  or  egress.  The  LLTR  node  sequence  on  egress  is  simply  the 
reverse  of  the  sequence  on  ingress.  Therefore,  one  can  read  down  the  list  to 
find  the  optimal  path  from  the  entry  point  to  the  exit  (for  ingress)  and  up  the 
list  to  find  the  optimal  path,  from  the  exit  back  to  the  entry  point  (for 
egress) . 

The  Low  Level  Transit  Route  Access  Array  has  a  direct  correspondence  to 
the  Transit  Route  Performance  (TRPE)  Array.  That  is,  one  vould  use  the  ITRC 
array  to  find  the  optimal  node  sequence  through  the  LLTR  network  and  the  TRPE 
array  to  find  the  distance  and  probability  of  arrival  along  this  path. 

The  ITRC  array  is  created  by  issuing  the  NODES  command.  There  are  as 
many  ITRC  records  as  there  are  LLTR  entry  points  which  are  accessible  to  at 
least  one  exit  point.  An  individual  ITRC  record  can  be  shown  by  specifying  the 
alphanumeric  LLTR  entry  point  name  or  its  unique  NLIS  index.  All  ITRC  records 
can  be  displayed  by  giving  the  "SHOV  ITRC  ALL"  command.  The  following  sample 
ITRC  table  could  have  been  generated  by  FLAPS  by  either  issuing  the  "SHOV  ITRC 
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M001"  or  "SHOV  ITRC  14"  commands. 

VRTREE  —  THERE  ARE  3  EXITS  ACCESSIBLE  TO  LLTR  ENTRY  POINT  N001  (  14) 


BRANCH  FOR  LLTR  EXIT  N150 


(  79) 


1 

N001 

( 

U) 

. 

4m 

N002 

( 

18) 

3 

N00  3 

( 

19) 

4 

N004 

( 

20) 

2 

N00  5 

( 

21) 

7 

N150 

( 

79) 

FOR 

LLTR  EXIT 

N151 

( 

1 

N001 

( 

14) 

2 

N002 

( 

18) 

3 

N010 

( 

22) 

4 

N011 

( 

23) 

5 

N012 

( 

24) 

6 

NO  13 

( 

25) 

3 

N151 

( 

30) 

FOR 

LLTR  EXIT 

N152 

( 

1 

NOOl 

( 

14) 

2 

N002 

( 

18) 

3 

NO  10 

( 

22) 

4 

N017 

( 

26) 

5 

N018 

( 

27) 

6 

N019 

( 

28) 

8 

N152 

( 

81) 

30) 


81) 
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DIST  =  173.60 


PA 


0.9946 


DIST  =  168.17  PA 


0.9948 


DIST  =  165.04 


PA 


0.9949 


.v 
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i 

r 


o 


t 
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A. 2.5  THE  MASK  (MASK)  ARRAY  FILE 


•  -'S 


The  mask  array  file  is  an  internal  file  to  the  software  and  is  not 
accessible  to  the  user.  The  mask  array  is  a  temporary  array  file  that  is  used 
during  the  masking  function.  It  is  stored  in  a  polar  coordinate  system  centered 
around  the  location  of  the  threat.  It  consists  of  a  set  of  rays  emanating  from 
the  threat  that  are  spaced  equal  angles  apart  in  degrees.  Along  each  ray  is  a 
set  of  points  that  are  spaced  equal  distances  apart.  The  minimum  observable 
altitude  is  calculated  for  each  point  along  the  ray,  and  the  ray  is  then  written 
out  to  the  mask  file.  Then,  the  mask  file  is  read  and  transformed  into  X,Y 
coordinates.  The  new  array  is  then  stored  in  the  file  "TOBS"  for  later  use  in 
creating  and  modifying  the  statespace,  implementing  threat  suppression,  and 
analyzing  routes.  The  parameters  for  creating  the  mask  array  are  stored  in  file 
"MSKEXT" .  See  SCT  Technical  Memo  5398-300  titled  "TERRAIN  MASKING  ALGORITHM" 
for  a  detailed  description  of  how  the  mask  array  file  is  created.  This  file  is 
not  available  for  showing  by  the  user.  The  default  dimensions  for  this  array 
are  shown  below.  Vhere  the  number  of  rays  *  120  and  the  number  of  points  along 
a  ray  =  125. 


MASK  =  1  1  120  125 


A.  2. 6  THE  MODE  30X  (MBOX)  .ARRAY 


The  Mode  Box  Array  consists  of  the  coordinates  of  a  box  around  each 
target.  The  box  is  stored  in  the  form:  minimum  longitude,  maximum  longitude, 
minimum  latitude,  and  maximum  latitude.  All  coordinates  are  in  decimal  degrees. 
The  box  defines  the  region  over  vhich  the  dynamic  programming  algoritnm  (DPA) 
vill  be  run.  Besides  the  target,  the  box  contains  all  of  the  accessiole  LLTR 
exit  points.  These  accessible  LLTR  exit  points  can  be  seen  by  showing  the  ITGC 
array.  The  optimal  ingress  and  egress  routes,  from  each  LLTR  exit  point  to  the 
target  vill  be  contained  within  the  box. 


The  Mode  3ox  Array  is  generated  by  the  ACCESS  command.  The  user  may  show 
this  array  after  this  command  has  been  run.  To  show  this  array  the  user  simply 
types  "SHOW  MBOX".  Mo  other  inputs  are  required.  The  output  will  be  in  the 
following  form:  "ID  "  refers  to  the  target  ID  name,  "INDEX"  refers  to  the  NUS 
indices.  The  box  coordinates  are  in  decimal  degrees.  The  following  table  was 
generated  by  FLAPS  after  a  "SHOW  NBOX"  was  entered. 


VRBOX  —  ARRAY 

NBOX 

—  DPA  BOX 

LIMITS 

ID 

INDEX 

MIN  LONG 

MAX  LONG 

MIN  LAT 

MAX  LAT 

COCHSTED 

1 

11.0 

12.9 

49.2 

52.0 

KOTHEN 

2 

11.0 

13.2 

48.0 

51.9 

ZOLLSCHN 

3 

11.0 

13.2 

43.0 

51.7 

CHKEUDHZ 

4 

11.0 

13.2 

43.2 

51.7 

LEIPZIG 

5 

11.0 

13.2 

48.0 

51.7 

BRANDIS 

6 

ii. o 

13.2 

48.2 

51.7 

DESSAU 

7 

11.0 

12.9 

49.2 

52.0 

KARLOVY 

3 

11.0 

13.2 

43.0 

51.7 

DOBRANY 

9 

11.0 

13.4 

48.0 

51.7 

ZATEC 

10 

11.0 

13.3 

48.0 

51.7 

PANENSKY 

11 

11.0 

14.1 

48.0 

51.7 

DREWITZ 

12 

11.0 

14.7 

49.4 

52.0 
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PRESCHEN 

13 

11.0 

14.8 

49.4 

51.8 

PRESHYST 

14 

11.0 

14.9 

48.0 

51.9 

ROTHENBG 

15 

11.0 

15.1 

48.0 

51.7 

BAUTZEN 

16 

11.0 

14.7 

•  49.2 

51.7 

PRAGUE 

17 

11.0 

14.4 

48.0 

51.7 

KLECANY 

18 

11.0 

14.5 

48.0 

51.7 

MILOVICE 

19 

11.0 

15.1 

48.0 

51.7 

SZPROTAU 

20 

11.0 

15.8 

48.0 

51.7 

CASLAV 

21 

11.0 

15.5 

49.2 

51.7 

LEGNICA 

22 

11.0 

16.1 

48.0 

51.7 

A-75 


u 


£1 


w 


->  -k  ■ 


•■  ',m.\±.l* 


A. 2. 7  THE  NODE  LIST  (NLIS)  ARRAY 


The  Node  Lis:  Array  is  an  ordered  list  of  all  active  nodes  in  the  current 
scenario.  The  nodes  are  ordered  in  the  sense  that  they  are  grouped  by  type. 

That  is,  the  first  entries  in  the  list  are  the  staging  bases.  Next  comes  the 
LLTR  entry  points,  followed  by  the  LLTR  intermediate  points  and  then  the  LLTR 
exit  points.  At  the  end  of  the  list  is  the  targets. 

The  Node  List  Array  only  contains  active  nodes.  Therefore,  it  does  not 
include  any  staging  bases  or  LLTR  points  that  are  not  contained  within  in  the 
scenario  boundaries.  Similarly,  it  does  not  include  any  targets  that  do  not  lie 
within  the  statespace  boundaries.  It  also  excludes  LLTR  nodes  which  are  turned 
off.  Keeping  this  list  as  small  as  possible  by  excluding  nodes  that  will  not  be 
usable  increases  processing  speed  and  minimizes  computer  memory  usage. 

The  structure  of  NLIS  is  very  simple  since  it  only  has  two  elements*,  the 
eight  character  alphameric  node  name  and  its  unique  integer  index.  These 
indices  can  be  used  in  commands  to  specify  a  node  instead  of  typing  in  the 
alphameric  node  ID.  Care  must  be  taken  that  a  current  version  of  NLIS  is  used 
since  the  indices  can  change  as  nodes  become  active  or  inactive  (i.e.  when  the 
NODES  command  is  given  after  changing  STGB,  LLTR  or  TG  data  bases  or  changing 
the  statespace  or  scenario  boundaries). 

There  is  only  one  Node  List  Array  record.  Usually,  it  is  suggested  that 
the  Node  Position  Array  (NPOS)  be  used  since  it  contains  all  of  the  information 
in  NLIS  and  the  node  position  information.  j  . 


The  Node  List  Array  is  generated  by  the  NODES  command.  To  show  this 


array  the  user  simply  types  ''SHOW  NLIS".  The  following  table  was  generated  by 
FLAPS  by  issuing  the  "SHOW  NLIS"  command. 

VRLIS  —  ARRAY  NLIS  LIST  OF  ID  NAMES 
INDEX  ID  NAME 

1  SMARSTON 

2  LAKENHTH 

3  MILDENHA 

4  BENTVATE 

5  BITBURG 

6  SPANGDAH 

7  HAHN 

8  RAMSTEIN 

9  SEMBACH 

10  LAHR 

11  SOLLING 

12  WIESBADN 


125  DREVITZ 

126  PRESCHEN 

127  PRESHYST 

128  ROTHENBG 

129  BAUTZEN 

130  PRAGUE 

131  KLECANY 

132  MILOVICE 

133  SZPROTAV 

134  CASLAV 

135  LEGNICA 


A. 2. 3  THE  NODE  POSITION  (NPOS)  ARRAY 

The  Node  Position  Array  is  very  similar  to  the  Node  List  Array  (NLIS). 

It  contains  ail  of  the  NLIS  information  and  all  of  the  comments  about  NLIS  apply 
to  NPOS  (see  section  3.2.7).  The  major  difference  between  the  tvo  arrays  is 
that  NPOS  also  includes  the  longitude  and  latitude  positions  of  the  nodes  (in 
decimal  degrees  with  the  convention  that  east  is  positive  for  longitude  and 
north  is  positive  for  latitude). 

It  is  suggested  that  the  NPOS  list  be  used  instead  of  the  NLIS  since  it 
contains  more  information  and  is  therefore  more  useful.  The  NPOS  array  is 
generated  by  the  NODES  command  and  will  change  when  this  command  is  given  if 
there  have  been  changes  made  to  the  STGBt  LLTR  or  TG  data  bases  or  to  the 
boundaries  of  the  statespace  or  scenario.  The  following  is  an  example  of  a  Node 
Position  Array  generated  by  FLAPS  by  issuing  the  "SHOW  NPOS"  command. 

VRPOS  —  ARRAYS  NPOS 


ID  NAME 

INDEX 

LONG 

LAT 

SMARSTON 

1 

-1.75 

51.58 

LAKENHTH 

2 

0.58 

52.40 

MILDENHA 

3 

0.50 

52.37 

BENTVATE 

4 

1.42 

52.13 

BITBURG 

5 

6.53 

49.97 

SPANGDAH 

6 

6.67 

49.93 

HAHN 

7 

7.25 

49.93 

RAMSTEIN 

3 

7.57 

49.43 

3EMBACH 

9 

7.88 

49.50 

LAflR 

10 

7.93 

43.37 

SOLLING 

11 

3.08 

43.78 

VIESBADN 

12 

3.33 

50.05 

N001 

14 

6.94 

50.45 

N031 

15 

7.07 

49.59 

S079 

16 

7.65 

49.29 

N156 

17 

-1.00 

52.00 

N002 

18 

7.44 

50.45 

N003 

19 

7.99 

50.78 

N004 

20 

3.59 

51.03 

COCHSTED 

KOTHEN 

ZOLLSCHN 

CHKEUDHZ 

LEIPZIG 

BRANDIS 

DESSAU 

KARLOVY 

DOBRANY 


PANENSKY 

DREVITZ 

PRESCHEN 

PRESHYST 

ROTHENBG 

BAUTZEN 

PRAGUE 

KLECANY 

MILOVICE 

SZPROTAV 

CASLAV 

LEGNICA 


12.70 

49.38 

12.87 

49.18 

13.01 

48.99 

12.54 

43 . 55 

11.62 

43.33 

12.19 

43.17 

11.10 

51.50 

11.10 

51.25 

11.10 

A. 2. 9  The  Route  (ROUT)  Array 


The  array  ROUT  contains  a  summary  of  the  hypothetical  sorties  generated 
by  the  command  "RO".  Each  sortie  consists  of  a  round  trip  route-aircraf t -weapon 
combination  vhich  is  optimal  for  its  target  and  staging  base.  The  criterion  for 
optimality  is  to  minimize  the  expected  number  of  lost  aircraft  among  all 
feasible  route-aircraft-weapon  combinations.  Feasible  here  means  that  the 
proposed  combination  is  consistent  with  the  aircraft  fuel  and  weapon 
characteristics  defined  in  table  VEHP,  and  achieves  the  probability  of  damage 
specified  for  the  target  in  table  TG. 


The  hypothetical  sorties  assigned  to  a  particular  target  may  be  examined 
using  the  "SHOW"  command  by  specifying  either  the  target  index  or  the  target  ID 
as  in  "SHOW  ROUT  119"  or  "SHOW  ROUT  LEGNICA".  In  addition  all  hypothetical 
sorties  may  be  examined  with  the  command  "SHOW  ROUT  ALL".  Illustrated  below  is 
the  summary  of  a  sortie  assigned  to  target  Legnica. 


T  A 

R  G  E  T 

:  LEGNICA 

PD 

ACHIEVED  :  0. 

9984 

STAGING 

LLTR 

LLTR 

DIST 

WEAP 

EXP 

BASE 

ENTRY 

EXIT 

(NM) 

PS  A/C 

TYPE 

LOSSES 

IN 

MILDENHA 

N156 

S102 

928.7 

0.876 

EG 

MILDENHA 

N156 

S102 

930.6 

0.919 

TOTAL 

1859.3 

0.805  2  Fill 

GB12 

0.390 

The  probability  of  target  damage  (PD)  shown  in  this  summary  represents 
only  the  effect  of  the  proposed  weapons  package  on  the  target  -  it  does  not 
reflect  the  probability  of  survival  (PS)  of  the  proposed  route.  Thus,  the  value 
of  PD  must  be  regarded  as  a  probability  of  damage  assuming  the  successful 
arrival  of  the  aircraft  at  the  target. 


The  detailed  routes  for  the  sorties  in  the  ROUT  array  nay  be  displayed 
graphically  by  using  the  DISPLAY  ROUTE  command  and  analyzed  for  threat  exposure 
using  the  ANALIZ  command.  However  it  is  first  necessary  that  the  routes  be 
selected  with  the  SELECT  command. 


A. 2. 10  THE  STATESPACE  (STAT)  ARRAY 

The  Statespace  Array  is  an  internal  file  that  is  used  by  the  softvare  and 
is  not  available  for  shoving  to  the  user.  It  is  stored  in  an  X,Y  coordinate 
system.  The  statespace  array  file  covers  the  operational  area  of  interest  for 
one  operational  altitude.  The  parameters  for  the  statespace  array  are  stored  in 
the  parameter  files  "ALGP"  and  "GEOM".  "STAT"  contains  the  danger  values  for  a 
given  altitude.  Prior  to  applying  suppression,  this  data  is  derived  from  the 
three  dimensional  statespace  array  "TH3D".  The  PROCESS  and  STATESPACE  ALTCPT 
commands,  described  in  section  2,  prompt  the  user  to  indicate  vhich  altitude 
level  he  wants  loaded  into  "STAT".  The  SUPPRESS  command,  described  in  section 
2.1.4,  re-calculates  STAT  to  take  into  account  the  lover  levels  of  danger 
produced  by  the  suppression  assets.  The  "STAT”  array  is  used  to  display  danger 
contours,  create  minimum  lethality  routes  from  the  staging  base  to  the  'targets 
and  back,  and  to  analyze  routes.  The  current  default  dimensions  for  this  array 
are  as  shown  below,  where  the  number  of  flight  directions  *  8,  the  number  of 
altitudes  =»  1,  the  number  of  longitude  increments  *  101,  the  number  of  latitude 
increments  »  114.  These  file  dimensions  are  printed  out  when  STAT  is  opened  by 
the  initialization  file  ZC0NTNU.DAT. 

STAT  =  8  1  101  114 


3  . 
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A. 2. 11  THE  STAGING  3ASE  TO  LLTR  EXIT  PERFORMANCE  (SXPE)  ARRAT 


The  Staging  3ase  to  LLTR  Exit  Performance  Array  gives  the  distance  in 
nautical  miles  and  probability  of  arrival  performance  data  for  the  optimal  path 
from  a  staging  base  to  a  LLTR  exit.  This  array  corresponds  record-by-record  and 
rov-by-rov  with  the  Target  Accessibility  Array  (ITGC).  Therefore,  there  is  one 
record  for  every  target  vhich  has  at  least  one  staging  base  accessib.e  to  it; 
and,  each  row  of  a  record  contains  the  performance  data  for  the  optimal  path 
from  the  staging  base  to  a  LLTR  exit  on  a  path  to  the  target. 


The  following  sample  SXPE  table  could  have  been  generated  by  FLAPS  either 
by  entering  the  command  "SHOW  SXPE  LEGNICA"  or  by  entering  the  command  "SHOW 
SXPE  135".  If  all  of  the  SXPE  records  are  desired,  the  command  "SHOW  SXPE  ALL" 


can  be  entered. 

VRSXPE  —  THERE  ARE  16  PATHS  TO  TARGET  LEGNICA  (  135) 

PATHS  FOR  STAGING  BASE  MILDENHA  (  3) 

LLTR  EXIT  DISTANCE  PROB  OF  ARRIVAL 


1 

S083 

( 

69) 

TO  EXIT 

607.93 

AT  EXIT 

0.9812 

2 

S039 

( 

70) 

596.60 

0.9815 

3 

S092 

( 

71) 

608.64 

0.9812 

4 

S102 

( 

72) 

614.23 

0.9810 

5 

S120 

( 

73) 

665.31 

0.9794 

6 

S133 

( 

74) 

690.98 

0.^786 

7 

S134 

( 

75) 

692.32 

0.9786 

3 

S135 

( 

76) 

667.62 

0. Q794 

9 

S136 

( 

77) 

630.13 

o.^sos 

10 

S137 

( 

73) 

654.74 

0.9797 

11 

N150 

( 

79) 

544.67 

0.9831 

12 

N151 

( 

30) 

539.24 

0.9833 

13 

N152 

( 

31) 

536.11 

0. Q834 

14  . 

N153 

( 

32) 

593.33 

0. J816 

15 

N154 

( 

33) 

585.71 

0.9819 

16 

S155 

( 

34) 

596.23 

0.9815 

A. 2. 12  The  Target  Status  (TGUS)  Array 


The  Target  Status  Array  TGUS  is  derived  from  the  array  ROUT  by  the 
weapons  allocation  command  "AL".  The  weapons  allocation  procedure  is  to  examine 
the  targets  in  order  of  decreasing  priority  and  to  select  for  each  the  feasible 
sortie  from  the  ROUT  array  with  minimum  expected  aircraft  losses.  Feasible  here 
means  that  the  total  number  of  aircraft  allocated  from  any  given  staging  base 
does  not  exceed  the  aircraft  inventory  for  that  base  as  defined  in  the  staging 
base  table  STGB,  that  the  aircraft  have  weapons  available  that  can  destroy  the 
target,  and  that  the  aircraft  can  carry  enough  fuel  to  reach  the  target  and 
return.  The  array  TGUS  consists  of  a  one  line  summary  of  each  of  these  selected 
sorties  listed  in  order  of  decreasing  target  priority. 


The  contents  of  TGUS,  which  resembles  an  air  tasking  order  (  ATO  ),  is 
examined  using  the  command  "SHOW  TGUS".  One  sample  is  illustrated  below. 


TARGET 

STAGING 

BASE 

AIRCRAFT 

ALLOCATED 

WEAPON 

TYPE 

PD 

ACHIEVED 

ROUTE 

PS 

ROUTE 
DIST  (NM) 

SZPROTAV 

SMARSTON 

2 

Fill 

GB10 

0.998 

0.16 

1760.0 

BAUTZEN 

SOLLING 

2 

F-4 

MK86 

0.942 

0.16 

808.9 

PANENSKY 

SEMBACH 

2 

F-16 

MK85 

0.858 

0.56 

757.8 

DOBRANY 

BITBURG 

2 

F-4 

MK82 

0.983 

0.22 

732.6 

ROTHENBG 

SMARSTON 

2 

Fill 

GB10 

0.998 

0.53 

1702.7 

ZOLLSCHN 

BITBURG 

2 

F-4 

MK8Z 

0.983 

0.08 

511.1 

DESSAU 

SOLLING 

2 

F-4 

MK86 

0.942 

0.60 

699.4 

BRANDIS 

BITBURG 

2 

F-4 

MK82 

0.983 

0.11 

808.3 

MILOVICE 

SEMBACH 

4 

F-16 

MK85 

0.980 

0.21 

826.0 

CHKEUDHZ 

SOLLING 

2 

F-4 

MK86 

0.942 

0.05 

648.2 

LEGNICA 

MILDENHA 

2 

Fill 

GB12 

0.998 

0.81 

1859.3 

PRESCHEN 

SOLLING 

2 

F-4 

MK86 

0.942 

0.19 

830.8 

KLECANY 

SEMBACH 

4 

F-16 

MK85 

0.980 

0.02 

782.5 

DREUITZ 

BITBURG 

2 

F-4 

MK82 

0.983 

0.84 

704.7 

PRESHYST 

MILDENHA 

2 

Fill 

GB12 

0.998 

0.81 

1763.1 

KARLOVY 

SEMBACH 

2 

F-16 

MK85 

0.858 

0.00 

570.8 

CASLAV 

BITBURG 

2 

F-4 

MK82 

0.983 

0.05 

799.2 

LEIPZIG 

- . 

- - 

—  NO 

ALLOCATION  ACHIEVED 

■- 

COCHSTED 

SOLLING 

2 

F-4 

MK86 

0.942 

0.98 

605.4 

ZATEC  SOLLING  2  F-4  HK86  0.942  0.56 

PRAGUE  -  NO  ALLOCATION  ACHI 

KOTHEN  -  NO  ALLOCATION  ACHI 


As  in  the  array  ROUT,  the  probability  of  damage  (P 


to  to 


A. 2. 13  THE  THREE  DIMENSIONAL  STATESPACE  (TH3D)  ARRAY  FILE 

The  three  dimensional  statespace  array  ''TH3D"  is  an  internal  file  that  is 
used  by  the  software  and  is  not  available  for  showing  to  the  user.  It  is  stored 
in  an  X,Y  coordinate  system.  The  array  ''TH3D"  covers  the  operational  area  of 
interest  for  all  the  operational  altitudes.  The  parameters  for  "TH3D"  are 
stored  in  the  parameter  files  "ALGP"  and  "GEOM".  To  load  data  into  array  "TH3D" 
you  type  the  commands  "ST  AD"  with  the  appropriate  parameters  as  prompted.  This 
causes  the  software  to  read  the  threat  observability  file  and  calculate  the 
danger  values  which  are  then  stored  in  array  "TH3D" .  The  array  "TH3D"  is  used 
to  load  data  into  the  array  "STAT"  for  doing  minimum  lethality  route 
calculations  and  threat  suppression.  The  danger  values  in  "TH3D"  can  be 
displayed  by  using  the  display  commands  described  elsewhere  in  this  document. 

The  current  default  dimensions  for  this  array  are  as  shown  below,  where  the 
number  of  flight  directions  *  8,  the  number  of  operational  altitudes  ■  5,  the 
number  of  longitude  increments  »  101,  and  the  number  of  latitude  increments  - 
114.  These  file  dimensions  are  printed  out  when  TH3D  is  opened  by  the 
initialization  file  ZC0NTNU.DAT. 


TH3D  »  8  5  101  114 


A. 2.14  THE  THREAT  OBSERVABILITY  (TOBS)  ARRAY  FILE 

The  threat  observability  file  is  an  internal  file  that  is  used  by  the 
softvare,  and  is  not  available  for  shoving  by  the  user.  The  "TOBS"  array 
contains  the  minimum  observable  altitude  for  each  threat  that  has  been  masked  by 
the  FLAPS  program.’  The  data  for  each  threat  is  stored  in  a  subarray  in  the 
"TOBS"  file  using  an  X,Y  coordinate  system  centered  around  the  threat  location. 
The  data  is  stored  in  sixteen  bit  integers  in  units  of  meters.  The  subarray  is 
intialized  to  32764  meters  before  terrain  masking.  The  "TOBS"  file  has  as  a 
header  an*  information  vord,  and  tvo  arrays.  The  information  vord  gives  the 
number  of  threats  that  have  been’ masked  and  stored  in  the  "TOBS”  file.  The 
first  array  consists  of  8  character  vords  that  identify  the  threats  that  have 
been  masked.  And  the  second  array  consist  of  integer  vords  that  are  pointers  to 
the  threat  subarrays  in  the  "TOBS"  file.  The  "TOBS"  file  is  dimensioned  as 
shown  below  where  256000  is  the  available  size  of  the  "TOBS"  file.  The  "TOBS" 
file  is  used  in  adding  or  deleting  threats  from  the  statespace,  doing  threat 
suppression,  and  doing  route  analysis.  The  following  file  dimensions  are 
printed  out  when  TOBS  is  opened  by  the  initialization  file  ZCONTNU.DAT. 


TOBS  »  256000  1  1  1 


A. 2. 15  THE  LCV  LEVEL  TRANSIT  ROUTE  PERFORMANCE  (TRPE)  ARRAY 

The  Low  Level  Transit  Route  Performance  Array  gives  the  performance  data 
for  the  optimal  node  sequences  through  the  LLTR  network.  Performance,  in  this 
case,  is  the  distance  in  nautical  miles  from  an  LLTR  entry  point  to  an  LLTR  exit 
point  and  the  probability  of  arrival  at  the  LLTR  exit  given  one  left  from  the 
LLTR  entry  point. 

This  array  corresponds  record-by-record  and  row-by-row  with  the  Low  Level 
Transit  Route  Accessibility  (ITRC)  Array.  Therefore,  there  is  one  record  for 
every  LLTR  entry  point  which  has  at  least  one  LLTR  exit  point  accessible  to  it; 
and,  every  row  in  a  record  contains  the  performances  from  the  entry  point  to  an 
accessible  exit  point.  Because  LLTR  exits  lie  on  the  friendly  side  of  the  FEBA, 
there  is  no  directionality  included  in  the  probability  of  arrival  calculations. 
This  means  that  the  probability  of  arrival  at  the  LLTR  exit  given  one  left  from 
the  LLTR  entry  is  the  same  as  the  probability  of  arrival  at  the  LLTR  entry  given 
that  one  left  from  the  LLTR  exit. 

The  following  TRPE  example  could  have  been  generated  by  FLAPS  either  by 
issuing  the  command  "SHOW  TRPE  N001"  or  by  issuing  the  command  "SHOW  TRPE  14". 

If  all  of  the  TRPE  records  had  been  desired  to  be  shown,  the  proper  command 
would  have  been  "SHOW  TRPE  ALL". 

VRTRPE  —  THERE  ARE  3  EXITS  ACCESSIBLE  TO  LLTR  ENTRY  POINT  N001  (  14) 


LLTR  EXIT 

DISTANCE 

PROB  OF  ARRIVAL 

1 

N150  ( 

79) 

173.60 

0.9946 

2 

N151  ( 

80) 

168.17 

0.9948 

3 

N152  ( 

81) 

165.04 

0.9949 

A. 2. 16  THE  FLIGHT  PLAN  (SPED) 


A  flight  plan  nay  be  generated  from  routes  stored  in  the  SPED  table  and 
displayed  on  the  users  terminal.  This  flight  plan  is  in  an  easily  interpreted 
form.  It  is  recommended  that  users  use  this  feature  instead  of  the  "SHOW  SPED" 
command . 

TV-.:  form  of  the  flight  plan  is  as  follows.  A  header  is  printed  which 
gives  the  name  of  the  sortie  (the  SPED  table  record  ID),  the  ID  and  index  of  the 
staging  base  and  target,  the  total  probability  of  survival,  the  probability  of 
kill  due  to  threats,  the  flight  distance  (in  nautical  miles),  the  take  off  time 
(in  decimal  minutes),  the  time  on  target  (in  decimal  minutes),  and  the  number  of 
waypoints.  These  are  all  labeled.  Refer  to  Section  3.1.10  for  a  description  of 
the  SPED  table.  The  actual  flight  plan  is  shown  as  a  list  of  waypoints.  Each 
waypoint  consists  of  time  (in  decimal  minutes),  latitude  and  longitude  (in 
degrees,  minutes  and  seconds),  altitude  (in  feet),  heading  (in  decimal  degrees 
from  north),  and  the  node  ID.  A  node  ID  will  appear  at  the  first  and  last 
waypoint  (the  staging  base),  at  the  target,  and  at  all  of  the  LLTR  points. 

Simple  turn  points  do  not  have  a  node  ID  listed. 

To  show  a  flight  plan,  the  user  should  type  "SHOW  PLAN".  FLAPS  will  then 
prompt  the  user  for  a  SPED  record  ID  or  a  record  number.  The  user  may  enter 
either,  whichever  is  more  convenient.  The  following  table  was  generated  by 
FLAPS  using  the  SHOW  PLAN  command  for  a  SPED  record  with  ID  BITB. CASL. 01 ,  and 
record  number  6.  The  plan  could  have 'been  generated  by  entering  either: 


SHOW  PLAN  3IT8.CASL.01 


SHOW  PLAN  6  f  J 

:-\>o 

VRPLAN  -  FLIGHT  PLAN  FOR  SORTIE:  BITB.CASL.01 

STAGING  BASE  BITBURG  (  5)  TO  TARGET  CASLAV  (  134) 

PROB  OF  SURVIVAL:  0.0482  THREAT  PK:  0.9518 

FLIGHT  DISTANCE:  799.22  NM 

TAKE  OFF  TIME:  0.0000  TIME  ON  TARGET:  41.3191  OF  WAYPOINTS 


TIME 

LATITUDE 

LONGITUDE 

ALTITUDE 

HEADING 

NODE  ID 

(MIN) 

(DMS) 

(DMS) 

(FEET) 

(DEG) 

0.000 

49 

58 

00 

6 

31 

59 

393.70 

132.86 

BITBURG 

6.212 

49 

17 

17 

7 

39 

15 

393.70 

105.47 

S079 

8.163 

49 

12 

17 

8 

06 

54 

393.70 

113.83 

S080 

10.722 

49 

02 

20 

8 

41 

14 

393.70 

100.43 

S097 

13.871 

48 

56 

52 

9 

26 

32 

393.70 

86.12 

S098 

16.694 

48 

58 

42 

10 

07 

44 

393.70 

85.53 

S099 

19.680 

49 

00 

56 

10 

51 

17 

393.70 

56.51 

S100 

22.673 

49 

16 

45 

11 

27 

57 

393.70 

52.05 

S101 

25.452 

49 

33 

08 

12 

00 

19 

393.70 

84.29 

S102 

28.454 

49 

35 

60 

12 

44 

33 

393.70 

45.21 

28.809 

49 

38 

24 

12 

48 

17 

393.70 

90.00 

29.565 

49 

38 

24 

12 

59 

29 

393.70 

45.17 

30.274 

49 

43 

12 

13 

06 

57 

393.70 

91.54 

39.585 

49 

40 

48 

15 

25 

06 

393.70 

0.00 

41.085 

49 

55 

12 

15 

25 

06 

393.70 

323.14 

41.319 

49 

57 

00 

15 

22 

60 

393.70 

229.92 

CASLAV 

42.774 

49 

47 

60 

15 

06 

26 

393.70 

206.70 

43.333 

49 

43 

12 

15 

02 

42 

393.70 

270.00 

46.099 

49 

43 

12 

14 

21 

37 

393.70 

225.40 

49.653 

49 

19 

12 

13 

44 

17 

393.70 

270.00 

50.413 

49 

19 

12 

13 

33 

05 

393.70 

225.42 

50.769 

49 

16 

48 

13 

29 

21 

393.70 

180.00 

51.019 

49 

14 

24 

13 

29 

21 

393.70 

225.47 

51.376 

49 

12 

00 

13 

25 

37 

393.70 

270.00 

53.663 

49 

12 

00 

12 

52 

01 

393.70 

302  21 

57.801 

49 

33 

08 

12 

00 

19 

393.70 

232.20 

S102 

60.580 

49 

16 

45 

11 

27 

57 

393.70 

236.65 

S101 

63.572 

49 

00 

56 

10 

51 

17 

393.70 

265.54 

S100 

66.558 

48 

58 

42 

10 

07 

44 

393.70 

266.12 

S099 

69.382 

48 

56 

52 

9 

26 

32 

393.70 

280.45 

S098 

72.531 

49 

02 

20 

8 

41 

14 

393.70 

293.90 

S097 

75.090 

49 

12 

17 

8 

06 

54 

393.70 

285.49 

S080 

77.041 

49 

17 

17 

7 

39 

15 

393.70 

313.26 

S079 

83.253 

49 

58 

00 

6 

31 

59 

393.70 

313.26 

BITBURG 

A. 2. 17  THE  3YTS  (.3YTE)  ARRAY  FILE 

The  byte  array  file  is  an  internal  file  chat  is  used  by  the  sofcvare  and 
is  not  available  for  showing  to  the  user.  It  contains  byte  packed  DTED  data 
that  is  in  an  SCT  format.  To  change  the  area  of  operation  requires  formatting  a 
new  data  file.  This  file  is  used  during  the  terrain  masking  process.  This  file 
has  a  header  shown  below  chat  is  described  for  the  current  scenario  as,  minimum 
longitude  *  11  degrees  east,  minimum  latitude  =  48  degrees  north,  maximum 
longitude  »  20  degrees  east,  maximum  latitude  =  54  degrees  north.  The  following 
file  dimensions  are  printed  out  when  BYTE  is  opened  by  the  initialization  file 
ZCONTNU-DAT. 

LUNTER , MXRCTR=*  0  0 

IHDR-  11.  48.  20.  54.  200  240  8  16 

A  stand  alone  program  called  FMBYTD  has  been  developed  by  SCT  to  create 
byte  packed  DTED  terrain  data  files. 


APPENDIX  B 
FLAPS  GLOSSARY 


AAA -  Antiaircraft  Artillery 

AAFCE - Allied  Air  Forces  Central  Europe 

ACCESSIBLE  NODE -  A  node  which  can  be  reached  directly 

from  another  node. 

ACCESSIBLE  NODES  BOX -  A  rectangular  area  containing  all  of 

the  nodes  which  can  be  reached  from 
a  given  node.  Used  by  the  DPA  when 
building  arcs. 

ACO -  Airspace  Coordination  Order 

AGL -  Altitude  Above  Ground  Level 

ALTG -  An  array  containing  the  optimal  altitude 

of  an  aircraft  above  the  ground. 

ALTS -  An  array  containing  the  optimal  altitude 

of  an  aircraft  above  sea  level. 

ARC - Path  between  two  nodes 

ATAF - Allied  Tactical  Air  Forces 

ATM - Air  Tasking  Messages 

ATO - Air  Tasking  Order 

ATOC - Allied  Tactical  Operations  Center 

CL3D - The  Three  Dimensional  Clobber  array 

COMPASS  CALL - Airborne  non-lethal  electronic  combat 

system 

COOKIE-CUTTER  TEMPLATE-  A  circular  uniform  threat  lethality 

model. 

CONTOUR  MAP(s) - Graphic  displays  of  terrain  heights; 

flight  altitudes;  roughness;  slope;  or 
danger.  Lines  are  plotted  to  show 
regions  of  equal  value  at  set  increments 

CORRIDOR - A  high  probabili ty-of-survival  route 

segment  through  which  sorties  will 
be  flovn;  created  by  applying  threat 
suppression  assets. 

DANGER - A  quantitative  representation  of  the 

threat  to  a  penetrating  aircraft  at  a 
location.  Mathematically,  the  negative 


DBMS - 

DCL - 

DIALOG  AREA- 


DMA - 

DOO - 

DPA - 

DTED — 

EC - 

EIFEL- 


ENTRY  LLTR  NODE- 


ENVELOPE- 


ESAMS- 


EVENT- 


e  y - 

EV/GCI- 


EXIT  LLTR  NODE- 


FEBA-- 

FLAPS- 

GCI - 

ID - 


INACTIVE  LLTR  NODE¬ 


INTERMEDIATE  LLTR  NODE- 


LLTR - 

LOCE - 

MICROVAX  II- 

NATO - 

NODE - 


NODE  INDEX- 


of  the  natural  logarithm  of  the 

combined  probability  of  survival  per  second 

Data  Base  Managment  System 

DEC  Command  Language 

The  part  of  the  terminal  screen  where 

the  user's  commands  are  entered  and  data 

and  messages  from  FLAPS  are  displayed. 

Defense  Mapping  Agency 

Daily  Operations  Order 

Dynamic  Programming  Algorithm 

Digital  Terrain  Elevation  Data 

Electronic  Combat 

Multi-national  automated  tactical 

command,  contraol,  and  information 

system. 

The  first  LLTR  node  an  aircraft  will 
encounter  upon  leaving  a  staging  base. 

A  region  defining  the  maximum  extent  of 
a  threat. 

Air  Force  approved  computer  program 
for  generating  radar  mission  templates. 

The  numeration  of  action  points  along  a 
route,  eg.  turn  point,  or  a  change  in 
threat  status.  • 

Electronic  Varfare 

Early  Varning/Ground  Control  Intercept 
Radar 

The  last  LLTR  node  an  aircraft  will  pass 
before  crossing  the  FEBA. 

Forward  Edge  of  Battle  Area 
Force  Level  Automated  Planning  System 
Ground  Control  Intercept  Area 
Identification,  in  FLAPS,  ID  usually 
refers  to  the  alphameric  name  of  some 
data  object. 

An  LLTR  node  which  is  not  available  for 
use  during  the  current  planning  cycle. 

Any  LLTR  node  which  is  available  for  use 
during  the  current  planning  cycle,  but 
which  cannot  be  reached  directly  from  a 
staging  base  and  cannot  directly  access 
the  FEBA. 

A  segment  of  a  route  between  consecutive 
turn  points. 

Low  Level  Transit  Route 

Limited  Operational  Capability  Europe 

A  small  32  bit  DEC  micro-computer 

North  Atlantic  Treaty  Organization 

Significant  route  points,  eg. 

staging  bases,  LLTR  points,  and  targets. 

A  unique  number  corresponding  to  every 
active  staging  base,  LLTR  point,  or 
target. 

Offensive  Counter  Air 

Probability  of  Arrival  for  penetrating 

aircraft 


■m  *■.  «■  ;*>.■  >■. y-iT. wjirn vj'W  •j>: s  s  v^ v_-  j-  y  - 


PD -  Probability  of  Destruction  of  target 

PEN-AIDS - Penetration  analysis  Aids  system  for 

tactical  air  forces. 

PK -  Probability  of  Kill  of  penetrating 

aircraft 

PS -  Probability  of  Survival  of  penetrating 

aircraf  t 

PRIMARY  COMMAND -  A  FLAPS  command  designed  to  be  used  by  a 

mission  planner. 

RCS -  Radar  Cross  Section 

ROZ -  Restricted  Operating  Zone 

SAM -  Surface- to-Air  Missile  System 

SCALAR - A  data  structure  containing  only  a 

single  element. 

SCENARIO  SPACE -  The  entire  geographical  region  under 

consideration  during  a  FLAPS  session. 

SCL -  Standard  Conventional  Load 

SCT -  Systems  Control  Technology,  Inc. 

SECONDARY  COMMAND -  A  FLAPS  command  designed  to  be  used  by 

program  developers. 

STALE  DATA - Data  generated  using  input  partameters 

or  data  bases  that  have  since  been 
modified,  eg.  routes  generated  using 
the  statespace  before  it  was  modified. 

STAT -  The  array  containing  the  current 

statespace. 

STATESPACE - Eight-directional  grid  collapsed  from 

two  or  3-dimensional  dangers.  Used  to 
determine  cost  of  travel  from  one  cell 
to  another. 

STATESPACE  CELL -  A  geographic  and  altitudinal  region  in 

which  the  probability  of  surviving 
threats  has  been  quantified. 

STOCHASTIC  THREAT -  A  mobile  threat  whose  location  is  only 

approximately  known  with  time. 

SURVIAC - The  Survivabili ty /Vulnerability 

Information  Analysis  Center 

SWITCH - A  data  construct  which  provides  the 

FLAPS  program  with  information  about  how 
it  is  currently  configured. 

TAC - Tactical  Air  Command 

TAC  ZINGER - Computer  program  simulating  Soviet 

defensive  sights  versus  penetration 
aircraft. 

TAF -  Tactical  Air  Forces 

TAFIG - Tactical  Air  Force  Inter-operability 

Group 

TEKTRONIX  4115-B  -  The  color  graphics  display  for  FLAPS. 

TERRAIN  FOLLOWING -  Flight  path  that  maintains  a  constant 

terrain  clearance  altitude. 

TERRAIN  MASKING -  Using  the  terrain  to  minimize  exposure 

to  threats. 

TF - Terrain  Following 

THREAT  MODEL - A  data  structure  which  contains  generic 

information  about  a  specific  type  of 
threat . 


B-3 


TH2D - An  array  containing  the  7vo  Dimensional 

Threat  environment  data. 

TH3D - An  array  containing  the  Three 

Dimensional  Threat  environment  data. 

TOT - Time  on  Target 

THEE - - - Optimum  sequence  of  LLTR  nodes  from  each 

LLTR  entry  point  to  all  accessible  LLTR 
nodes . 

USAFE - United  States  Air  Forces  Europe 

VAX  11/750  - A  32  bit  DEC  mini-computer  upon  which 

will  run  the  FLAPS  program. 

VECTOR - A  data  structure  which  contains  many 

elements . 

'WAYPOINT - A  point  on  a  route  where  one  or  more  of 

the  flight  parameters  change,  eg. 
heading  or  altitude. 

WILD  7EASEL - Aircraft  configured  with  airborne 

lethal  defense  suppression  weapons. 

VFZ - Weapons  Free  Zone 


